显示记录，其实再简单不过了，一条sql语句即可 Select * From T_Class order By F_RootID,F_Orders 下面给出一个A...
-- ======================================== -- Author: <杨俊明,jimmy.yang@cntvs.c...
无限分类是一个老生常谈的话题了，网上有很多解决方案，可以分成二个流派，一种利用递归，一种利用非递归(当然需要其它一些辅助手段判断节点层次)，但核心表结构都差不多，有三个关键字段(ID主键,ParentId
-- ============================= -- Author: <杨俊明,Jimmy.yang@cntvs.com or yjmyz...
一、背景需求 当我们需要在多个数据库间进行数据的复制自动增长型字段可能造成数据合并时的主键冲突。...设想一个数据库中的Order表向另一个库中的Order表复制数据库时，OrderID到底该不该自动增长呢？...数据库自增长ID和无序的UUID方案的不足之处： 1）、采用数据库自增序列：数据迁移合并等比较麻烦。...（主要是索引查询销量不是最高的） 如果非要使用非自主增长列作为主键的话(分布式系统分库分表中)，推使用有序UUID和有序的整长的Rowid(雪花算法snowflake和MongoDB之ObjectId...1)、无序UUID： string guid = Guid.NewGuid().ToString(); string guid = Guid.NewGuid().ToString("N"); 缺点
数据库设计主键类型的选择 数据库设计表时，主键（主属性...）的数据类型选择bigint还是GUID呢 在做数据库设计时，数据库主键以及其类型的选择犹为重要。...通常数据库主键字段的类型常被设计成 int（bigint）或 GUID 或自定义的格式类型，学习总结主键数据类型的选择。...1 int （bigint）类型 (推荐） （1）简洁易懂 （2）易于排序，分页等操作处理 （3）可以通过设置sequence设置自增 （4）sequence主从表关联速度较快 2 GUID 类型 （...（2）易于定位、数据迁移（ int 类型，容易造成混乱） （3）不存在重复id问题，数据合并时非常简单。
该项目使用的数据库是MSSQL LocalDB。并已经做好了上述Models的迁移工作。 该数据库里面存在过一些数据，但是现在都被我删除了。...然后看看会发生什么 生成的迁移类 命令：Add-Migration Xxx 看一下生成的迁移类的内容： 生成的SQL脚本 命令：Script-Migration 这是里面关于插入数据的部分： 迁移到数据库...看下生成的迁移文件： 先删除了之前添加的Id为2的种子数据，然后把插入了一笔Id为3的数据。 看下SQL： 也是先Delete，再Insert。 数据库里： 种子数据为什么要指定主键的值？ ...如果主键是Guid类型呢？ 看下数据： 貌似没问题。 如果我不修改这个种子数据，再执行一次迁移呢？ 看一下这时的迁移文件： 删除原来的数据，再插入一个新的数据。。...数据库里也是这样的： 所以最好的办法是把Guid的值放在一个变量里： 然后再操作一遍： 这样就不会出现“把原有数据删掉，再重新插入”这种操作了。
该项目使用的数据库是MSSQL LocalDB。并已经做好了上述Models的迁移工作。 该数据库里面存在过一些数据，但是现在都被我删除了。...这里我添加了一个省份的种子数据，并写上了主键Id的值。 数据库该表的主键Id是int自增的。Id为1的数据曾经存在过，但是被我删除了。...迁移到数据库 命令：Update-Database -Verbose ? 结果是成功的。 看红线那两句话，EFCore在执行的过程中临时更改了设置，可以插入主键的值，然后又禁用了插入主键。...迁移后的数据： ? 结果仍然如预期一样。 如果主键是Guid类型呢？ ? 看下数据： ? 貌似没问题。 如果我不修改这个种子数据，再执行一次迁移呢？ 看一下这时的迁移文件： ?...数据库里也是这样的： ? 所以最好的办法是把Guid的值放在一个变量里： ? 然后再操作一遍： ? 这样就不会出现“把原有数据删掉，再重新插入”这种操作了。
功能特点 自动迁移实体结构（CodeFirst），到数据库； 直接操作实体的方法，进行 CRUD 操作； 简化用户定义实体类型，省去主键、常用字段的配置（如CreateTime、UpdateTime...int 并且自增的实体类型，BaseEntity TKey 指定为 int/long 时，会认为主键是自增； public class UserGroup : BaseEntityGuid 的实体类型，保存数据时会自动产生有序不重复的 Guid 值（不用自己指定 Guid.NewGuid()）； public class User : BaseEntityGuid> { public string UserName { get; set; } } 3、定义多主键的实体类型，可以在 static 构造函数中重写字段名； public class...User2 : BaseEntityGuid, int> { static User2() { User2.Orm.CodeFirst.ConfigEntity
主键设计的争议 关于数据库主键设计的一些原则与所采用的技术，园子中有大量的文章讨论，我选择两片具体代码性的文章，听棠.NET的数据库主键设计之思考和zhenyulu的小议数据库主键选取策略...关于数据库主键设计的一些原则与所采用的技术，园子中有大量的文章讨论，我选择两片具体代码性的文章，数据库主键设计之思考与小议数据库主键选取策略（原创）两篇文章。 ...在数据库主键设计之思考一文中，作者把数据库主键设计讲的很透彻，他也提出了主键设计与具体业务无关的论点： “我强调主键不应该具有实际的意义，这可能对于一些朋友来说不太认同，比如订单表吧，会有“订单编号”...ITEMVALUE from eas.IDENTITYVALUES where ITEMKEY = @itemKey COMMIT TRANSACTION GO 值可以采用整性或者长整性进行存储...，而如GUID这样的没有办法在将来支持扩展分区的设计。
妄自菲薄，请大家多指出错误，并给出意见 数据库设计三范式基本原则 第一范式：数据库表中的字段都是单一属性的，不可再分。...关于主键： 我比较倾向于主键的业务无关性，用的是著名的GUID。虽然占用空间较大，效率也偏低，但是在找不出其它更好的方法。...需要注意的是，建立主键时，SQL Server默认会把主键设置为聚合索引，一定要把他去掉，设置在更有意义的其它字段上，或者压根就不设。 GUID的好处很多，有： 生成主键简单，可预知。...没有并发时主键重复的烦恼。 防止用户手动更改数据库中的数据，一看到GUID，就都吓回去了。 避免数据库表迁移时的麻烦（用自增型的主键，在表迁移时简直就是灾难）。...避免了基础表更新时外键的级联更新（主要体现在主键业务无关性上）。 欢迎大家多提意见。
[Table("Book")] public class Book { private Guid id; public Guid Id...book表（不需要此刻已经有Book表），使用[Required]特性来表明字段是否可为空，此外，由于EF默认将Id属性视为主键，所以无需使用[Key]特性来指明上面的Id为主键。...EF Database Migration EF数据库迁移 首先启用迁移功能。...完成了迁移之后，查看数据库： 我们可以看到，表及其结构按照我们预期创建成功了。...[Table("EBook")] public class EBook { private Guid id; public Guid Id
单精度Fload双精度Double，建议一律用Double，否则不同数据库很难统一，还有千万小心精度设置和小数位数，XCode反向工程可能不能把精度和小数位数完美的迁移到其它类型数据库，同类型没有问题。...DateTime，各种数据库，一律用时间日期DateTime，不支持单独的Date或Time的迁移。...在.Net中同为String，根据不同数据库的字符串最大长度（MSSQL是4000），识别为nvarchar还是ntext。 最佳体验： 1，单一主键，建议用自增ID。...新增的表间关系是通过猜测得到的，规则：字段名等于另一个表名加主键名时，认为是外键 3，不要用Guid类型和二进制类型，XCode只能支持正向工程，不能支持它们的反向工程。...可用nvarchar(32)替代Guid 4，字符串尽量不要用varchar/char等，因为不同数据库甚至相同数据库的不同版本，差别好大。这样省不了多少空间。 5，尽可能的不要用默认值。
int，习惯了Guid，当然也为了更方便迁移数据，因为int会乱序，特别是在多库的时候。...那这个时候如果我想把int主键，改成guid，工作量是多大，需要改多少地方，怎么处理逻辑，前端修改哪些地方，等等等等。...所以我就尝试了这个新课题：使用泛型主键，这样拿到这个项目的时候，自己修改下主键类型，就可以运行了，不过目前还没有百分百完善，int主键已经调通，其他类型主键，比如Guid或者自定义string还没有完成生产化...定义好了基类，那我们就需要动手数据库实体类了，可能稍微复杂一点，因为会涉及另一个重要的概念。...的时候，注意修改命名空间，别生成到了数据库里，当然肯定也生成不进去，会报错的，这里只是提个醒，因为是CodeFirst的逻辑是根据命名空间： // 创建数据库表，遍历指定命名空间下的class
趋势递增：在主键的选择上面我们应该尽量使用有序的主键保证写入性能。 单调递增：保证下一个ID一定大于上一个ID。...C# 中叫 GUID(Globally Unique IDentifier) UUID有五算法分别是什么？为什么UUID会重复？为什么会出现MAC泄露？...基本不影响 优点： 它允许在客户端确定主键,而不需要通过数据库往返来生成Id值. GUID是自然唯一的在以下情况下有一些优势; 你需要与外部系统集成, 你需要拆分或合并不同的表....不像雪花算法、号段 需要特定的配置 可以是有序的GUID 在向数据库插入新记录时,这可以提高性能并允许我们在与数据库交互之前知道PK. 缺点： 不易于存储：UUID太长，16字节128位。...除非在做数据迁移。不过真到了那个时候一点一点迁移呗。 我们建表时一定要尽量做到单表查询。且字段里的值不要过于太大。
缺点 不同数据库的语法和实现不同，数据库迁移或者数据库版本支持的时候需要处理 在单个数据库或读写分离或者一主多从的情况下，只有一个主库可以生成，可能会造成单点故障。...全球唯一，在遇见数据迁移，系统数据合并，或者数据库变更时，很难产生冲突，较易解决。...在其主键生成方式中提供了Comb算法（combined guid/timestamp）。...保留GUID的10个字节，用另6个字节表示GUID生成的时间（DateTime）。...后面3个是直接生成的GUID。
这部分就不详细展开了，详见 无限级分类(非递归算法/存储过程版/GUID主键)完整数据库示例_(1)表结构 无限级分类(非递归算法/存储过程版/GUID主键)完整数据库示例_(2)插入记录 无限级分类...(非递归算法/存储过程版/GUID主键)完整数据库示例_(3)删除记录 无限级分类(非递归算法/存储过程版/GUID主键)完整数据库示例_(4)显示记录 稍微啰唆几句： 1.1 我习惯于把所有表加上前缀...1.3 之所以用guid做为主键，主要是考虑到数据库迁移时的方便，当然guid主键会带来一些性能上的损失（二害相权，取其轻也），为了改进可将guid改为comb主键(详见 “Integer GUID和Comb...做主键的效率测试”) 1.4 考虑到很多人为了各种原因喜欢把分类页生成静态页，而为了url地址的简短/友好，guid主键有些长，所以我又添加了一个辅助字段F_AutoId，这样生成的静态页可以从类似"43A6162C...在这些特定情况下，关系型数据库(不管是sqlserver还是oracle)的查询能力都是无能为力的，如果您去百度一下关于搜索引擎的数据库设计，几乎看不到采用关系型数据库做为查询核心的。
由于云计算环境的规则与内部部署环境不同，因此在顺利进行迁移之前，应先对数据库进行适当的清理工作。...这种方法也可以应用于将SQL Server数据库迁移到云平台中。由于云计算环境的规则与内部部署环境不同，因此在顺利进行迁移之前，应先对数据库进行适当的清理工作。...检查阶段：数据库质量检查 由于在迁移过程中不应对应用程序和数据库进行任何更改，因此必须消除任何妨碍可靠性能的功能。必须进行额外的质量检查，以确保应用程序和数据库级别之间的平滑交互。...•GUID(全局唯一标识符)不用作聚集索引。这仅适用于未扩展的小型表格。还必须检查是否将GUID用作集群主键，因为这会导致许多性能问题。...特别是，当使用对象关系映射(ORM)工具时，更容易发生转换问题，因为对象关系映射(ORM)通常默认情况下使用GUID作为集群索引。 此外，应再次检查查询超时的编码。
主键的数据类型 最常见的主键数据类型是数字类型、固定长度的字符类型和GUID类型。...GUID类型：这个类型并不是所有数据库都有对应的数据类型，SQL Server有uniqueidentifier，MySQL没有。...数据库主键与业务主键 前面说到一个表可能有很多个唯一标识的候选键，那么这么多候选键中，哪个应该拿来做主键呢？...GUID，这是用于GUID类型的主键，可以使用newid()这种数据库提供的函数，或者使用程序生成Guid并赋值。 Hilo值，这是一种使用高低位算法生成的数字值的主键。...，但是由于我们大部分情况下都是使用主键检索数据，所以大部分数据库的默认实现，在建立主键时会自动建立对应的索引。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
云直播
