精华内容
下载资源
问答
  • 主关键字(PRIMARY KEY):主键是表中的一个或多个字段,它的值用于唯一地标识表中的某一条记录。 外键(FOREIGN KEY):如果公共关键字在一个关系中是主关键字,那么这个公共关键字被称为另一个关系的外键。由此可见...

    定义

    • 主关键字(PRIMARY KEY):主键是表中的一个或多个字段,它的值用于唯一地标识表中的某一条记录。

    • 外键(FOREIGN KEY):如果公共关键字在一个关系中是主关键字,那么这个公共关键字被称为另一个关系的外键。由此可见,外键表示了两个关系之间的相关联系。以另一个关系的外键作主关键字的表被称为主表,具有此外键的表被称为主表的从表。外键又称作外关键字。

    • 聚集索引:聚集索引是指数据库表行中数据的物理顺序与键值的逻辑(索引)顺序相同。一个表只能有一个聚集索引,因为一个表的物理顺序只有一种情况,所以,对应的聚集索引只能有一个。如果某索引不是聚集索引,则表中的行物理顺序与索引顺序不匹配,与非聚集索引相比,聚集索引有着更快的检索速度。

    • 非聚集索引:非聚集索引是一种索引,该索引中索引的逻辑顺序与磁盘上行的物理存储顺序不同。

    • 自动编号列和标识符列:对于每个表,均可创建一个包含系统生成的序号值的标识符列,该序号值以唯一方式标识表中的每一行。

    • 业务主键(自然主键):在数据库表中把具有业务逻辑含义的字段作为主键,称为“自然主键(Natural Key)”。

    • 逻辑主键(代理主键):在数据库表中采用一个与当前表中逻辑信息无关的字段作为其主键,称为“代理主键”。

    • 复合主键(联合主键):通过两个或者多个字段的组合作为主键

    使用逻辑主键原因

    业务变化

    • 使用逻辑主键的主要原因是:业务主键一旦改变则系统中关联该主键部分的修改将会是不可避免的,并且引用越多改动越大。而使用逻辑主键则需要修改主键相关的业务逻辑即可,减少了业务主键相关改变对系统的影响。业务逻辑的改变是不可避免的,因为“永远不变是变化”,没有任何一个公司是一成不变的,没有任何一个业务是永远不变的。最典型的例子就是身份证升位和驾驶执照号换用身份证号的业务变更。而且现实中也确实出现了身份证号码重复的情况,这样如果用身份证号码作为主键也带来了难以处理的情况。当然应对改变,可以又很多解决方案,方案一是做一个新的系统与时俱进,这对软件公司说确实是好事。

    主键过大不利于传输、处理和存储

    • 使用逻辑主键的另外一个原因是,业务主键过大,不利于传输、处理和存储。我认为一般如果业务主键超过8字节就应该考虑使用逻辑主键了,因为int是4字节的,bigint是8字节的,而业务主键一般是字符串,同样是 8 字节的 bigint 和 8 字节的字符串在传输和处理上自然是 bigint 效率更高一些。想象一下 code == “12345678” 和 id == 12345678 的汇编码的不同就知道了。当然逻辑主键不一定是 int 或者 bigint ,而业务主键也不一定是字符串也可以是 int 或 datetime 等类型,同时传输的也不一定就是主键,这个就要具体分析了,但是原理类似,这里只是讨论通常情况。同时如果其他表需要引用该主键的话,也需要存储该主键,那么这个存储空间的开销也是不一样的。而且这些表的这个引用字段通常就是外键,或者通常也会建索引方便查找,这样也会造成存储空间的开销的不同,这也是需要具体分析的。
    • 使用逻辑主键的再一个原因是,使用 int 或者 bigint 作为外键进行联接查询,性能会比以字符串作为外键进行联接查询快。原理和上面的类似,这里不再重复。

    人为因素

    • 使用逻辑主键的再一个原因是,存在用户或维护人员误录入数据到业务主键中的问题。例如错把 RMB 录入为 RXB ,相关的引用都是引用了错误的数据,一旦需要修改则非常麻烦。如果使用逻辑主键则问题很好解决,如果使用业务主键则会影响到其他表的外键数据,当然也可以通过级联更新方式解决,但是不是所有都能级联得了的。

    使用业务主键的原因

    • 使用业务主键的主要原因是,增加逻辑主键就是增加了一个业务无关的字段,而用户通常都是对于业务相关的字段进行查找(比如员工的工号,书本的 ISBN No. ),这样我们除了为逻辑主键加索引,还必须为这些业务字段加索引,这样数据库的性能就会下降,而且也增加了存储空间的开销。所以对于业务上确实不常改变的基础数据而言,使用业务主键不失是一个比较好的选择。另一方面,对于基础数据而言,一般的增、删、改都比较少,所以这部分的开销也不会太多,而如果这时候对于业务逻辑的改变有担忧的话,也是可以考虑使用逻辑主键的,这就需要具体问题具体分析了。

    安全问题

    • 使用业务主键的再一个原因是,对于银行系统而言安全性比性能更加重要,这时候就会考虑使用业务主键,既可以作为主键也可以作为冗余数据,避免因为使用逻辑主键带来的关联丢失问题。如果由于某种原因导致主表和子表关联关系丢失的话,银行可是会面临无法挽回的损失的。为了杜绝这种情况的发生,业务主键需要在重要的表中有冗余存在,这种情况最好的处理方式就是直接使用业务主键了。例如身份证号、存折号、卡号等。所以通常银行系统都要求使用业务主键,这个需求并不是出于性能的考虑而是出于安全性的考虑。
    • 使用业务主键的另外一个原因是,对于用户操作而言,都是通过业务字段进行的,所以在这些情况下,如果使用逻辑主键的话,必须要多做一次映射转换的动作。我认为这种担心是多余的,直接使用业务主键查询就能得到结果,根本不用管逻辑主键,除非业务主键本身就不唯一。另外,如果在设计的时候就考虑使用逻辑主键的话,编码的时候也是会以主键为主进行处理的,在系统内部传输、处理和存储都是相同的主键,不存在转换问题。除非现有系统是使用业务主键,要把现有系统改成使用逻辑主键,这种情况才会存在转换问题。暂时没有想到还有什么场景是存在这样的转换的。
    • 使用业务主键的再一个原因是,对于银行系统而言安全性比性能更加重要,这时候就会考虑使用业务主键,既可以作为主键也可以作为冗余数据,避免因为使用逻辑主键带来的关联丢失问题。如果由于某种原因导致主表和子表关联关系丢失的话,银行可是会面临无法挽回的损失的。为了杜绝这种情况的发生,业务主键需要在重要的表中有冗余存在,这种情况最好的处理方式就是直接使用业务主键了。例如身份证号、存折号、卡号等。所以通常银行系统都要求使用业务主键,这个需求并不是出于性能的考虑而是出于安全性的考虑。
    • 使用复合主键的主要原因和使用业务主键是相关的,通常业务主键只使用一个字段不能解决问题,那就只能使用多个字段了。例如使用姓名字段不够用了,再加个生日字段。这种使用复合主键方式效率非常低,主要原因和上面对于较大的业务主键的情况类似。另外如果其他表要与该表关联则需要引用复合主键的所有字段,这就不单纯是性能问题了,还有存储空间的问题了,当然你也可以认为这是合理的数据冗余,方便查询,但是感觉有点得不偿失。
    • 使用复合主键的另外一个原因是,对于关系表来说必须关联两个实体表的主键,才能表示它们之间的关系,那么可以把这两个主键联合组成复合主键即可。如果两个实体存在多个关系,可以再加一个顺序字段联合组成复合主键,但是这样就会引入业务主键的弊端。当然也可以另外对这个关系表添加一个逻辑主键,避免了业务主键的弊端,同时也方便其他表对它的引用。
    • 综合来说,网上大多数人是倾向于用逻辑主键的,而对于实体表用复合主键方式的应该没有多少人认同。支持业务主键的人通常有种误解,认为逻辑主键必须对用户来说有意义,其实逻辑主键只是系统内部使用的,对用户来说是无需知道的。

    结论或推论:

    1、尽量避免使用业务主键,尽量使用逻辑主键。

    2、如果要使用业务主键必须保证业务主键相关的业务逻辑改变的概率为0,并且业务主键不太大,并且业务主键不能交由用户修改。

    3、除关系表外,尽量不使用复合主键。

    (想自学习编程的小伙伴请搜索圈T社区,更多行业相关资讯更有行业相关免费视频教程。完全免费哦!)

    展开全文
  • 什么是逻辑主键和业务主键

    千次阅读 2019-03-10 18:11:46
    逻辑主键(surrogate key):无意义的字段,即自增长字段,即identity。这其中还有一个选择GUID(Globally Unique Identifier)。 也叫代理主键。 业务主键(natrual key):有意义的字段,比如身份证 ID。也叫...

    定义:

    逻辑主键(surrogate key):无意义的字段,即自增长字段,即identity。这其中还有一个选择GUID(Globally Unique Identifier)。  也叫代理主键。

     

     

    业务主键(natrual key):有意义的字段,比如身份证 ID。也叫自然主键

     

    维基百科介绍:

    在关系数据库设计中,业务主键是一个由以及真实存在于世界中的属性构成的键。业务主键对于逻辑主键的主要优势在于(逻辑主键在脱离数据库环境时没有任何意义)业务主键已经存在,因此没有必要去添加新的人工的列到定义中。

    展开全文
  • 逻辑主键:没有业务含义,比如自增主键业务主键:有业务含义,比如person表用身份证号当主键插入性能用逻辑主键的情况下,插入的过程中需要定位到页再插入,效率上会比直接追加到最后一个数据页要低很多。...

    2ff34e647e2e3cdfd8dca593e17d9b0a.png

    逻辑主键:没有业务含义,比如自增主键

    业务主键:有业务含义,比如person表用身份证号当主键

    插入性能

    用逻辑主键的情况下,插入的过程中需要定位到页再插入,效率上会比直接追加到最后一个数据页要低很多。

    相比之下,辅助索引带来的多一次的IO的开销其实并不一定很大,因为一方面Innodb本身有缓存,除非全表的随机扫描,否则在大部分业务情况下,访问基本都是可以命中缓存的。另一方面一个自增有序的主键其实在很多业务场景中,比如分页,排序等都会利用的上。而且innodb表对于主键的回盘查询效率是很高的。

    比较倾向于建一个自增的id做主键,再将有业务含义的主键字段添加唯一索引的约束。如果可以的话,跨表关联查询时使用自增的id做为表关联的条件,不过这种情况下要对要不要在关联的表中保存业务主键字段做个权衡。

    插入性能依赖插入顺序(主键).因为插入数据时需要按照主键寻找相应的页再进行插入,如果数据页不在内存中所以需要进行加载.

    主键在插入新行或更新时导致移动行的时候可能会造成页分裂的问题.

    当行主键值必须插入到一个已满的内存页中时Innodb会将该页分裂成两个页面来容纳数据行.分裂操作会导致表占用更多的磁盘空间.

    如果可以保证业务字段能够有序的插入可以放弃自增主键使用业务字段当做主键.

    总结对比

    1、Innodb引擎是索引组织表,所谓索引组织表就是数据的插入顺序是根据主键的顺序来的,如果设置业务ID为主键,没有办法保证业务ID自增的话,那么新数据的插入会引起行迁移,这就是为什么很多回答中提到自增主键会提升插入效率。

    2、Innodb引起表中所有的二级索引(非主键)的key值记录的都是主键,所以尽量要求主键的字段类型简单,而业务开发一般会用char/varchar来设计业务ID,用varchar和int来设计主键,影响的不仅仅是主键的长度,该表上所有的索引都会变大。从SQL优化的角度来说,优化的本质是减少IO,而减少IO最直接的方法其实就是设计最简单的字段类型(包括索引)。

    3、从运维DBA的角度来说,非自增主键,十几亿条记录的表,要分批操作时候的绝望吗?如果有自增主键,直接指定primary key操作,会大大简化后期维护操作。当然可以通过updatetime字段来操作,但是不一定所有的表都有自更新的时间戳字段啊,而且也不一定能保证时间戳有索引。

    4、如果表只有几百条数据,也不会有什么分批操作的需求,这就跟要不要设计索引一样。当然考虑实际情况或者业务场景,这样的表不设主键或索引也是可以接受的,但是从开发规范来说,难道制定主键规范的时候只说大家根据实际需求来吗?

    所以一般的开发规范中都会要求设计自增ID为主键。

    展开全文
  • 这几天对逻辑主键业务主键和复合主键进行了一些思考,也在网上搜索了一下相关的讨论,相关讨论可以看最下面的参考链接。下面是自己基于 SQL Server 做的一些总结,其他数据库(Oracle、MySQL、DB2、......)应该也...

    这几天对逻辑主键、业务主键和复合主键进行了一些思考,也在网上搜索了一下相关的讨论,相关讨论可以看最下面的参考链接。下面是自己基于 SQL Server 做的一些总结,其他数据库(Oracle、MySQL、DB2、......)应该也类似吧。这个只是自己一时的思考,如有不当请告知,重新思考后再修正。

     

    定义(部分定义来源于 SQL Server 联机丛书):

    主键(PRIMARY KEY):表通常具有包含唯一标识表中每一行的值的一列或一组列。这样的一列或多列称为表的主键 (PK),用于强制表的实体完整性。

    外键(FOREIGN KEY):外键 (FK) 是用于建立和加强两个表数据之间的链接的一列或多列。在外键引用中,当一个表的列被引用作为另一个表的主键值的列时,就在两表之间创建了链接。这个列就成为第二个表的外键。

    聚集索引:聚集索引基于数据行的键值在表内排序和存储这些数据行。每个表只能有一个聚集索引,因为数据行本身只能按一个顺序存储。

    非聚集索引:非聚集索引包含索引键值和指向表数据存储位置的行定位器。可以对表或索引视图创建多个非聚集索引。通常,设计非聚集索引是为改善经常使用的、没有建立聚集索引的查询的性能。

    自动编号列和标识符列:对于每个表,均可创建一个包含系统生成的序号值的标识符列,该序号值以唯一方式标识表中的每一行。

    业务主键(自然主键):在数据库表中把具有业务逻辑含义的字段作为主键,称为“自然主键(Natural Key)”。

    逻辑主键(代理主键):在数据库表中采用一个与当前表中逻辑信息无关的字段作为其主键,称为“代理主键”。

    复合主键(联合主键):通过两个或者多个字段的组合作为主键。

     

    原理分析:

    使用逻辑主键的主要原因是,业务主键一旦改变则系统中关联该主键的部分的修改将会是不可避免的,并且引用越多改动越大。而使用逻辑主键则只需要修改相应的业务主键相关的业务逻辑即可,减少了因为业务主键相关改变对系统的影响范围。业务逻辑的改变是不可避免的,因为“永远不变的是变化”,没有任何一个公司是一成不变的,没有任何一个业务是永远不变的。最典型的例子就是身份证升位和驾驶执照号换用身份证号的业务变更。而且现实中也确实出现了身份证号码重复的情况,这样如果用身份证号码作为主键也带来了难以处理的情况。当然应对改变,可以有很多解决方案,方案之一是做一新系统与时俱进,这对软件公司来说确实是件好事。

    使用逻辑主键的另外一个原因是,业务主键过大,不利于传输、处理和存储。我认为一般如果业务主键超过8字节就应该考虑使用逻辑主键了,因为int是4字节的,bigint是8字节的,而业务主键一般是字符串,同样是 8 字节的 bigint 和 8 字节的字符串在传输和处理上自然是 bigint 效率更高一些。想象一下 code == "12345678" 和 id == 12345678 的汇编码的不同就知道了。当然逻辑主键不一定是 int 或者 bigint ,而业务主键也不一定是字符串也可以是 int 或 datetime 等类型,同时传输的也不一定就是主键,这个就要具体分析了,但是原理类似,这里只是讨论通常情况。同时如果其他表需要引用该主键的话,也需要存储该主键,那么这个存储空间的开销也是不一样的。而且这些表的这个引用字段通常就是外键,或者通常也会建索引方便查找,这样也会造成存储空间的开销的不同,这也是需要具体分析的。

    使用逻辑主键的再一个原因是,使用 int 或者 bigint 作为外键进行联接查询,性能会比以字符串作为外键进行联接查询快。原理和上面的类似,这里不再重复。

    使用逻辑主键的再一个原因是,存在用户或维护人员误录入数据到业务主键中的问题。例如错把 RMB 录入为 RXB ,相关的引用都是引用了错误的数据,一旦需要修改则非常麻烦。如果使用逻辑主键则问题很好解决,如果使用业务主键则会影响到其他表的外键数据,当然也可以通过级联更新方式解决,但是不是所有都能级联得了的。

    使用业务主键的主要原因是,增加逻辑主键就是增加了一个业务无关的字段,而用户通常都是对于业务相关的字段进行查找(比如员工的工号,书本的 ISBN No. ),这样我们除了为逻辑主键加索引,还必须为这些业务字段加索引,这样数据库的性能就会下降,而且也增加了存储空间的开销。所以对于业务上确实不常改变的基础数据而言,使用业务主键不失是一个比较好的选择。另一方面,对于基础数据而言,一般的增、删、改都比较少,所以这部分的开销也不会太多,而如果这时候对于业务逻辑的改变有担忧的话,也是可以考虑使用逻辑主键的,这就需要具体问题具体分析了。

    使用业务主键的另外一个原因是,对于用户操作而言,都是通过业务字段进行的,所以在这些情况下,如果使用逻辑主键的话,必须要多做一次映射转换的动作。我认为这种担心是多余的,直接使用业务主键查询就能得到结果,根本不用管逻辑主键,除非业务主键本身就不唯一。另外,如果在设计的时候就考虑使用逻辑主键的话,编码的时候也是会以主键为主进行处理的,在系统内部传输、处理和存储都是相同的主键,不存在转换问题。除非现有系统是使用业务主键,要把现有系统改成使用逻辑主键,这种情况才会存在转换问题。暂时没有想到还有什么场景是存在这样的转换的。

    使用业务主键的再一个原因是,对于银行系统而言安全性比性能更加重要,这时候就会考虑使用业务主键,既可以作为主键也可以作为冗余数据,避免因为使用逻辑主键带来的关联丢失问题。如果由于某种原因导致主表和子表关联关系丢失的话,银行可是会面临无法挽回的损失的。为了杜绝这种情况的发生,业务主键需要在重要的表中有冗余存在,这种情况最好的处理方式就是直接使用业务主键了。例如身份证号、存折号、卡号等。所以通常银行系统都要求使用业务主键,这个需求并不是出于性能的考虑而是出于安全性的考虑。

    使用复合主键的主要原因和使用业务主键是相关的,通常业务主键只使用一个字段不能解决问题,那就只能使用多个字段了。例如使用姓名字段不够用了,再加个生日字段。这种使用复合主键方式效率非常低,主要原因和上面对于较大的业务主键的情况类似。另外如果其他表要与该表关联则需要引用复合主键的所有字段,这就不单纯是性能问题了,还有存储空间的问题了,当然你也可以认为这是合理的数据冗余,方便查询,但是感觉有点得不偿失。

    使用复合主键的另外一个原因是,对于关系表来说必须关联两个实体表的主键,才能表示它们之间的关系,那么可以把这两个主键联合组成复合主键即可。如果两个实体存在多个关系,可以再加一个顺序字段联合组成复合主键,但是这样就会引入业务主键的弊端。当然也可以另外对这个关系表添加一个逻辑主键,避免了业务主键的弊端,同时也方便其他表对它的引用。

    综合来说,网上大多数人是倾向于用逻辑主键的,而对于实体表用复合主键方式的应该没有多少人认同。支持业务主键的人通常有种误解,认为逻辑主键必须对用户来说有意义,其实逻辑主键只是系统内部使用的,对用户来说是无需知道的。

     

    结论或推论:

    1、尽量避免使用业务主键,尽量使用逻辑主键。

    2、如果要使用业务主键必须保证业务主键相关的业务逻辑改变的概率为0,并且业务主键不太大,并且业务主键不能交由用户修改。

    3、除关系表外,尽量不使用复合主键。

     


    使用逻辑主键的最佳实践指南:

    1、足够用就好。系统使用的生命周期以100年为限,逻辑主键数据类型采用下表规则,如果不确定则使用int类型。

    数据量    数据类型    数据大小    生成频率    备注
    < 128    tinyint    1 字节    1条/年    频率过低,不太靠谱,不建议采用
    < 3 万    smallint    2 字节    27条/月    频率较低,慎用
    < 21 亿    int    4 字节    40条/分钟    能满足大部分情况
    < 922 亿亿    bigint    8 字节    292万条/毫秒    能满足绝大部分情况 
    >= 922 亿亿    uniqueidentifier    16 字节    
    100亿用户同时每毫秒生成10亿条,可以连续生成10亿年

    可用于分布式、高并发的应用
    2、一般采用自增长方式或NewID()方式。

    3、主键字段名称一般采用“表名ID”方式,方便识别和表联接。

    4、如果表存在分布式应用,则可以考虑采用不同起始值,相同步长方式自增。例如有3个部署在不同地方的库,则可以如下设计:

    起始值    步长
    1    10
    2    10
    3    10
    步长统一设置10是为了方便日后扩展,这样不同库之间也能保持主键唯一性了,也方便合并。

    5、如果存在高并发性需求或数据表迁移需求,可以考虑使用uniqueidentifier类型,并使用NewID()函数。

    6、可以考虑对业务主键建立唯一性索引,以实现业务主键唯一性的业务需求。

    7、如果需要考虑业务主键的性能需求,可以把业务主键建立聚集索引,而逻辑主键只建立主键约束和非聚集索引即可。

    8、关系表可以考虑采用复合主键方式,复合主键不用于实体表。
     

    展开全文
  • 原有的数据库表的设计中,很多表中都是用了联合主键 ,因为这样的设计符合业务上的概念,而且原生的jdbc数据库访问也不存在使用联合主键的困难。 但是,现在一切变了,一方面,我们享受者hibernate的面向对象的变量...
  • 逻辑主键业务主键和复合主键

    千次阅读 2018-07-17 00:09:49
    外键(FOREIGN KEY):外键 (FK) 是用于建立加强两个表数据之间的链接的一列或多列。在外键引用中,当一个表的列被引用作为另一个表的主键值的列时,就在两表之间创建了链接。这个列就成为第二个表的外键。 聚集...
  • 关于业务主键和逻辑主键的思考 这几天对逻辑主键业务主键和复合主键进行了一些思考,也在网上搜索了一下相关的讨论,相关讨论可以看最下面的参考链接。下面是自己基于 SQL Server 做的一些总结,其他数据库...
  • 关于业务主键和逻辑主键

    千次阅读 2017-11-03 22:00:52
    业务主键(自然主键):在数据库表中把具有业务逻辑含义的字段作为主键,称为“自然主键(Natural Key)”。 ...使用逻辑主键的主要原因是,业务主键一旦改变则系统中关联该主键的部分的修改将会是
  • 谈谈企业信息系统数据库设计是使用id主键还是uuid逻辑主键业务主键
  • 逻辑主键业务主键和复合主键的思考

    万次阅读 多人点赞 2010-05-10 14:54:00
    这几天对逻辑主键业务主键和复合主键进行了一些思考,也在网上搜索了一下相关的讨论,相关讨论可以看最下面的参考链接。下面是自己基于 SQL Server 做的一些总结,其他数据库(Oracle、MySQL、DB2、......)应该也...
  • 逻辑主键和物理主键

    千次阅读 2018-07-04 08:37:26
    逻辑主键一般是用来表示一个包含确切意义的并唯一的键值,可根据逻辑主键的值了解到一些具体信息。 在大项目中,一般用物理主键,方便数据库的迁移,因为在数据迁移过程中可能物理主键会存在这样或那样的问题,...
  • 刚读完一篇文章http://www.cnblogs.com/xhyang110/archive/2009/11/04 /1595943.html?login=1#commentform,博主的观点是主键应该都是无意义的,不要和业务相关。我很疑惑,疑惑为什么说应该无意义呢,这个应该无...
  • 逻辑主键业务主键

    千次阅读 2016-03-10 22:21:31
    提示对逻辑主键业务主键和复合主键的思考 —— 资料来源 逻辑主键存在用户或维护人员误录入数据到业务主键中的问题。例如错把 RMB 录入为 RXB ,相关的引用都是引用了错误的数据,一旦需要修改则非常麻烦。如果...
  • 1业务主键(natrual key),有意义的字段。 2逻辑主键(surrogate key),无意义的字段,即自增长字段,即identity。这其中还有一个选择GUID。 
  • 详细说说业务主键和非业务主键

    千次阅读 2020-08-21 17:50:53
    挖坑待填,先挖个坑,稍后来填。。 数据库设计,为什么要有业务主键和非业务主键,各自的应用场景是什么。
  • 业务变化,不影响,不需要更新主键。 缺点:无法转移数据库,比如把表中的一批数据 转移 或 附带到 另一个表中,那么由于是自增长字段,那么会导致无法转移,因为另外一个表可能已经存在部分数据,会造成主键冲突。...
  • 这几天对逻辑主键业务主键和复合主键进行了一些思考,也在网上搜索了一下相关的讨论,相关讨论可以看最下面的参考链接。下面是自己基于 SQL Server 做的一些总结,其他数据库(Oracle、MySQL、DB2、......)应该也...
  • 逻辑删除与业务主键

    2020-01-10 17:33:48
    假设某个表的业务主键列包括:col1、col2、col3。 有些公司有规定,程序里不允许物理删除(即delete from …),只能逻辑删除,即新增一个类似于yn_flag的列,1表示正常,0表示删除。 此时,如何在表中建唯一键呢?...
  • 业务主键逻辑主键

    2018-10-22 02:35:00
    不过采用什么样的字段来做为主键字段还是一个必须解决的问题,目前有两种常用的主键策略:业务主键逻辑主键业务主键是指采用业务数据中的某个字段做为主键,比如在员工档案表中可以用工号来做为主键、在车辆...
  • 最近参与的项目,其公共模块(单位表、人员信息表等)全部使用的是代理主键,而集成进来的数据模型又使用的是逻辑主键。为了最大限度的使用已经写好的存储过程、函数等对象,公共模块的数据必须按照一定规则映射一份...
  • 昨天令狐因为处理动网论坛的数据库时,发现它是用帖子号来作为主键,由于无意中对它作了一些...我起初也觉得用一个无意义的逻辑主键是一个好办法,至少说用一个字段就可以唯确定一条记录,使用上会很方便,速度应...
  • 业务主键和逻辑主键

    千次阅读 2013-06-06 17:30:39
    业务主键(自然主键):与表中的内容有关,有实际意义。 逻辑主键(代理主键):与表中的内容无关,没有任何意义,只是为了对表中的行内容进行区分。如:1、2、3、4... 复合主键(联合主键):通过两个或者多个...
  • 在bs开发中用到权限系统,用到几张表涉及到userid,roleid等主键,我现在比较想用逻辑主键,这样比较清晰确定记录,可是有个毛病要用到SEQUENCE,这样就要建好几个SEQUENCE也挺烦的,大家设计一般采用啥作主键,我...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 82,546
精华内容 33,018
关键字:

逻辑主键和业务主键