跟着杨中科学习(四)EFCore(二)

主键

自增主键

• 自动增长。优点:简单;缺点:数据库迁移以及分布式
  系统中比较麻烦;并发性能差。long、int等类型主键,默
  认是自增。因为是数据库生成的值,所以SaveChanges后
  会自动把主键的值更新到Id属性。试验一下。场景:插入
  帖子后,自动重定向帖子地址。
• 自增字段的代码中不能为Id赋值,必须保持默认值0,
  否则运行的时候就会报错。

Guid主键

• Guid算法(或UUID算法)生成一个全局唯一的Id。适合于分布式
  系统,在进行多数据库数据合并的时候很简单。优点:简单,高并发,
  全局唯一;缺点:磁盘空间占用大。
• Guid值不连续。使用Guid类型做主键的时候,不能把主键设置为
  聚集索引。因为聚集索引是按照顺序保存主键的,因此用Guid做主键性能差。比如MySQL的InnoDB引擎中主键是强制使用聚集索引的。
• 有的数据库支持部分的连续Guid,比如SQLServer中的
  NewSequentialId(),但也不能解决问题。在SQLServer等中,不要
  把Guid主键设置为聚集索引;在MySQL中,插入频繁的表不要用
  Guid做主键。
• 演示Guid用法:既可以让EF Core给赋值,也可以手动赋值(推
  荐)。

0 个引用
class Rabbit
{
    public Guid Id {get; set;}//主键
    
    public string Name {get; set;}//标题
}

    Rabbit r1 = new Rabbit();
    r1. Id= Guid. NewGuid() ;
    r1.Name= "yzk";
    Console. WriteLine(r1. Id) ;
    ctx. Rabbits. Add(r1) ;
    Console. WriteLine(r1. Id) ;
    await ctx. SaveChangesAsync();
    Console. WriteLine(r1. Id) ;

其他方案

• 混合自增和Guid(非复合主键)。用自增列做物理的主键,而用
  Guid列做逻辑上的主键。把自增列设置为表的主键,而在业务上查询数据时候把Guid当主键用。在和其他表关联以及和外部系统通讯的时候(比如前端显示数据的标识的时候)都是使用Guid列。不仅保证了性能,而且利用了Guid的优点,而且减轻了主键自增性导致主键值可被预测带来的安全性问题。
• Hi/Lo算法:EF Core支持Hi/Lo算法来优化自增列。主键值由两
  部分组成:高位(Hi)和低位(Lo),高位由数据库生成,两个高位之间间隔若干个值,由程序在本地生成低位,低位的值在本地自增生成。不同进程或者集群中不同服务器获取的Hi值不会重复,而本地进程计算的Lo则可以保证可以在本地高效率的生成主键值。但是HiLo算法不是EF Core的标准。

Migrations的深入了解

• 使用迁移脚本,可以对当前连接的数据库执行编号更高
  的迁移,这个操作叫做“向上迁移”(Up),也可以执行
  把数据库回退到旧的迁移,这个操作叫“向下迁移”
  (Down)。
• 除非有特殊需要,否则不要删除Migrations文件夹下
  的代码。

EFCore的随机迁移命令

• Update-Database XXX
  把数据库回滚到XXX的状态,迁移脚本不动。
• Remove-migration
  删除最后一次的迁移脚本
• Script-Migration
  生成迁移SQL代码。
• 可以生成版本D到版本F的SQL脚本:
  Script-Migration D F
• 生成版本D到最新版本的SQL脚本:Script-Migration D

EFCore的反向工程

类似于DBFirst。

根据数据库表来反向生成实体类。

输入指令：

Scaffold-DbContext
'Server =.; Database=demo1;Trusted
Connection=True;MultipleActiveRes
ultSets=true'
Microsoft.EntityFrameworkCore.SqlS
erver

EFCore操作数据库

了解EFCore的底层原理：反射加泛型，底层还是ADO.NET Core

EFCore底层依然是ADO.NET