主键
自增主键
- 自动增长。优点:简单;缺点:数据库迁移以及分布式
系统中比较麻烦;并发性能差。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
标签：r1,数据库,主键,中科,EFCore,Guid,Id,跟着 From： https://www.cnblogs.com/guan-tou6/p/18237579