1. Re:数据库中主键和外键的设计原则
[quote]pinglexp： 支持楼主的言论 如果像后面的人所说的，要考虑性能，性能不是单单凭主键去优化的，而且等业务逻辑复杂的时候，单纯的主键也提高不了性能。 等你的数据量达到千万以上的级别的...
--安羽.
2. Re:数据库中主键和外键的设计原则
实践过博主说的主键自动生成对用户无意义,好处是从应用层面很多东西可以改,如部门表的部门编码(有实际意义),在组织结构变化比较大的情况也可以改.但坏处是开发维护以及平时思维被迫增加了很多麻烦,很多时候是...
--归来兮
3. Re:Visual Studio 2008 从头创建你的web站点
在看您的文章, 想学东西. 是否可以联系. 我的qq : 76542296 . msn : ehblan@hotmail.com 我接触asp.net 刚开始. 基本东西知道了需要看看类似您这样的实...
--hblan
4. Re:需求该如何分析？
当然是先梳理、描述清楚业务流程， 然后再分析、总结关键对象。 当然在梳理业务流程的时候要时刻有对象的观念。
--laoding
5. Re:数据库中主键和外键的设计原则
支持楼主的言论 如果像后面的人所说的，要考虑性能，性能不是单单凭主键去优化的，而且等业务逻辑复杂的时候，单纯的主键也提高不了性能。 等你的数据量达到千万以上的级别的时候，后期维护代价可想而知。 如...
--pinglexp
阅读排行榜
1. 数据库中主键和外键的设计原则 (9793)
2. 第一篇：使用Visual Studio 2008布局页面(9367)
3. 第六篇：ListView控件与DataPager控件详解（1）(9330)
4. Visual Studio 2008 从头创建你的web站点(6943)
5. 企业级开发的权限管理(4610)
评论排行榜
1. Visual Studio 2008 从头创建你的web站点(35)
2. 第一篇：使用Visual Studio 2008布局页面(35)
3. 企业级开发的权限管理(26)
4. 第六篇：ListView控件与DataPager控件详解（1）(21)
5. 是瀑布还是迭代敏捷（讨论）？(20)
数据库中主键和外键的设计原则
主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。
必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境，就很难对这些键进行修改，所以在开发阶段就设计好主键和外键就是非常必要和值得的。
主键：
关系数据库依赖于主键---它是数据库物理模式的基石。主键在物理层面上只有两个用途：
1. 惟一地标识一行。
2. 作为一个可以被外键有效引用的对象。
基于以上这两个用途，下面给出了我在设计物理层面的主键时所遵循的一些原则：
1. 主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。
2. 主键应该是单列的，以便提高连接和筛选操作的效率。
注：使用复合键的人通常有两个理由为自己开脱，而这两个理由都是错误的。其一是主键应当具有实际意义，然而，让主键具有意义只不过是给人为地破坏数据库提供了方便。其二是利用这种方法可以在描述多对多关系的连接表中使用两个外部键来作为主键，我也反对这种做法，理由是：复合主键常常导致不良的外键，即当连接表成为另一个从表的主表，而依据上面的第二种方法成为这个表主键的一部分，然，这个表又有可能再成为其它从表的主表，其主键又有可能成了其它从表主键的一部分，如此传递下去，越靠后的从表，其主键将会包含越多的列了。
3. 永远也不要更新主键。实际上，因为主键除了惟一地标识一行之外，再没有其他的用途了，所以也就没有理由去对它更新。如果主键需要更新，则说明主键应对用户无意义的原则被违反了。
注：这项原则对于那些经常需要在数据转换或多数据库合并时进行数据整理的数据并不适用。
4. 主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等。
5. 主键应当有计算机自动生成。如果由人来对主键的创建进行干预，就会使它带有除了惟一标识一行以外的意义。一旦越过这个界限，就可能产生认为修改主键的动机，这样，这种系统用来链接记录行、管理记录行的关键手段就会落入不了解数据库设计的人的手中。
? 下一篇：企业级开发的权限管理
posted on 2008-04-02 13:02 tianyamoon 阅读(9793) 评论(13) 编辑 收藏 所属分类: 只是转载
FeedBack:
#1楼 2008-10-20 10:47 sciland[未注册用户]
很不错，希望与你直接交流，请你给我你的联系方式，如qq
回复 引用
#2楼 2009-01-22 13:36 NewSea.
1 。主键的第二个用途 是错误 的。
唯一索引 也可以作为外键被引用对象。
2。 主键原则第一条也是错误 的。导致第二条也是错误 的。
不知博主从哪里听说： 主键必须是无意义的。
主键在一些情况下，代表的是系统关系的联系对象。比如 公文ID ， 它对用户是无意义的，
而有一些情况下，比如人的身份证号 ， 或 省会编码。 可以用作主键。并且，它是有意义的。
综上所述。 博主之文章， 实在毫无意义。
回复 引用 查看
#3楼 2009-03-08 22:18 出cc[未注册用户]
良好的设计就是主键无意义
回复 引用
#4楼 2009-03-31 13:06 littlered[未注册用户]
--引用--------------------------------------------------
NewSea.:
2。 主键原则第一条也是错误 的。导致第二条也是错误 的。
不知博主从哪里听说： 主键必须是无意义的。
主键在一些情况下，代表的是系统关系的联系对象。比如 公文ID ， 它对用户是无意义的，
而有一些情况下，比如人的身份证号 ， 或 省会编码。 可以用作主键。并且，它是有意义的。
综上所述。 博主之文章， 实在毫无意义。
--------------------------------------------------------
身份证会升位的，省会会变直辖市的，这些的变更如果要影响到你所有的主键和外键，就是大工程了。
什么都不懂就乱鄙视你，真不知道应该笑你无知还是说你可悲
回复 引用
#5楼 2009-05-08 11:25 源声依旧
有一家帮助，集思广义
回复 引用 查看
#6楼 2009-05-09 01:09 qcrsoft[未注册用户]
"不知博主从哪里听说： 主键必须是无意义的"
——一定是要是听来的吗？相信是楼主从实践中总结来的
做了十年数据库设计，我的经验是主键的作用是唯一标识行数据，它不应当参与业务。除去楼主所说的一切外，还有一点很有说服力：前端代码好写
比如用身份证号做主键，假如身份证号录入错误（即使概率相当小系统也必须有要考虑）需要修改你需要做哪些工作？你需要首先修改各个用身份证做外键的表里的身份证号对吗？哎等等，新改正的身份证号在主表里还不存在，数据库不给你写那~~~先改主表里身份证号？主外键约束着也不给你改那，啊对，用级联更新，可是各个数据库对级联更新是有差异的哦
如果你编写WIN32的程序，你会发现comboBox、listbox们的value只能放数值，不能放字符，如果主键是字符，编码会需要曲线的把数据和控件绑定在一起
等等等等。。。。没有最好的，只用更好的，做的多了，你就会发现按楼主说的去做，至少你的代码写起来要舒服
劝NewSea多多实践，细心总结
回复 引用
#7楼 2009-06-11 18:57 ktstudio1[未注册用户]
我不是太同意楼主的观点。
原因如下：
我们应该在性能和可扩展性之间寻求平衡，而不是这种极端的做法。
如今的应用程序已不同于早期的只负责填写的简单程序，应用程序的更多任务是为需要从数据库中获取特定数据的人服务。不仅如此，我们的应用程序即使在提供一些简单功能时，往往也需要从一系列数据库主键中进行遍历，如果此时的数据记录主键没有任何业务特性，我们就不得不采用记录中的其他能够说明记录含义的字段来参与遍历，而这些字段甚至没有经过查询优化处理，更不要说跟主键的性能相比了。
事务独立性也非常重要。
事实上我们应该尽量将有意义的字段作为记录的主键，它不仅可以提高数据遍历的性能，在作为相关记录的外键时也更加有意义。
在有些开发者看来，他们从不考虑性能的因素。因为他们已习惯将性能指标交由硬件厂商。不幸的是，他们的应用程序也从不考虑高效的数据交换。
当他们开始交换数据时，他们一般都会说，这简直是要命的。因为他们的应用程序在宝贵的交换通道上传输着很多无意义的数据，因而也需要多个步骤才能完成整个过程。不幸的是，如果其中某个步骤出现异常，这个过程往往需要重来一遍。
我暂时说这么多。总之一句话，凡事不能太绝对。
作者的思想也能解决一些问题，不过只是在初期。当你再深入的时候，你就会发现，解决数据的关联性问题，只不是需要一种标准的手段，而且往往并不难，也有很多的可参考的标准和代码。这些问题迟早不再是你的问题。而你因为解决这些问题引入的固化思想可能是致命的。
回复 引用
#8楼 2009-06-24 15:25 slotbeta
同意LZ的说法，主键只用来唯一标识一行记录就OK，参与到业务中真是自找麻烦！虽然过去的时间很长了，但是不免说了这么句！
回复 引用 查看
#9楼 2009-08-13 20:09 Single[未注册用户]
引用
ktstudio1：我不是太同意楼主的观点。
<br/>原因如下：
<br/>我们应该在性能和可扩展性之间寻求平衡，而不是这种极端的做法。
<br/>如今的应用程序已不同于早期的只负责填写的简单程序，应用程序的更多任务是...
非常同意此种观点。
回复 引用
#10楼 2009-08-17 15:31 ben10303050[未注册用户]
我刚问了我的数据库老师，他说最好是有意义的，身份证还真是特例，身份证升位的话就停一下服务器，系统维护一下就好了，毕竟身份证升位是几十年才一次的。
身份证输错了的话，就先新增一条正确的身份证，然后改外键的那些表，最后删掉母表里面的错误的那一条就行了。
回复 引用
#11楼 2009-12-15 15:13 pinglexp[未注册用户]
支持楼主的言论
如果像后面的人所说的，要考虑性能，性能不是单单凭主键去优化的，而且等业务逻辑复杂的时候，单纯的主键也提高不了性能。
等你的数据量达到千万以上的级别的时候，后期维护代价可想而知。
如果你是小系统，那是无所谓，哈哈，想怎么怎么的。
回复 引用
#12楼 2010-06-25 10:44 归来兮
实践过博主说的主键自动生成对用户无意义,好处是从应用层面很多东西可以改,如部门表的部门编码(有实际意义),在组织结构变化比较大的情况也可以改.但坏处是开发维护以及平时思维被迫增加了很多麻烦,很多时候是没必要的. 不同意把这个原则绝对化,博主太武断了.
回复 引用 查看
#13楼 2010-10-31 15:10 安羽.
引用
pinglexp：
支持楼主的言论
如果像后面的人所说的，要考虑性能，性能不是单单凭主键去优化的，而且等业务逻辑复杂的时候，单纯的主键也提高不了性能。
等你的数据量达到千万以上的级别的时候，后期维护代价可想而知。
如果你是小系统，那是无所谓，哈哈，想怎么怎么的。
支持楼主、支持pinglexp，不要为性能（或其它方面）找借口，设计本源是为了好用、实用、简单化（易用）（荐＜软件开发的科学与艺术＞的软件设计之源部分），数据库设计的性能指标只是综合性能指标的一部分，优化性能方式有好多方案，就微软自己总结出来的：与其花数周或数月时间与人力做设计、算法的优化才提高百分之十几性能，不如新买一个最新的中等价格多核服务器提高50％～200％的性能来的有效。（当然我也不反对优化，优化还是很重要的）数据库中主键用表视角代表一行唯一的数据，用ER关系视角（表是实体模板）行是一个实体的实例，用面象对象的视角是一个可确定对象。这样看来主键可以有意义也可以无意义，有意义时主键对于对象（或实体、行）的是有一个有意义属性，无意义时主键的属性只有一个意义就标识对象。我想楼主有目的把主键主动设计为无意义认为是好的设计这也无可厚非，从设计本源这样没错（我也是这样实践的），因为无论从哪种视角主键唯一标识的特性是不变的，这是行、实体、对象的根基，标识不变说明对象（行、实体）是确定的，再去访问修改属性都会简单易行。把事件复杂化、讲什么大理论，把问题搞的玄而又玄，不是什么好设计，设计的目的是为了：简。
没有放之四海而皆准的真理，真理是有条件的。
＠NewSea
"唯一索引 也可以作为外键被引用对象。"也不能说明：“主键作为一个可以被外键有效引用的对象。 “是错误的。你都说”也可以“了，为什么还说人家是错的。
******************************************************************************************************************************************************
数据库建模外键大讨论(1)
来自乱世经典
最近在做一个派单系统数据库设计，在设计中有些疑惑的地方中午在网上发起一个话题讨论. 我把这个讨论流程.发过来 大家可以可以看看.
也可以发表一下自己的意见.
对于主/外键/索引来说，在一些开发团队中被认为是处理数据库关系的利器，也被某些开发团队认为是处理某些具体业务的魔鬼，您的观点呢？在实际应用中您会采取哪种方式？
大家共同观点：
主键和索引是不可少的，不仅可以优化数据检索速度，开发人员还省不其它的工作,
矛盾焦点：数据库设计是否需要外键。这里有两个问题：一个是如何保证数据库数据的完整性和一致性；二是第一条对性能的影响
2009-11-11 13:07 changShaHacker
正方观点：
1，由数据库自身保证数据一致性，完整性，更可靠，因为程序很难100％保证数据的完整性，而用外键即使在数据库服务器当机或者出现其他问题的时候，也能够最大限度的保证数据的一致性和完整性。
eg：数据库和应用是一对多的关系，Ａ应用会维护他那部分数据的完整性，系统一变大时，增加了Ｂ应用，Ａ和Ｂ两个应用也许是不同的开发团队来做的。他们如何协调保证数据的完整性，而且一年以后如果又增加了C应用呢？
2，有主外键的数据库设计可以增加ER图的可读性，这点在数据库设计时非常重要。
3，外键在一定程度上说明的业务逻辑，会使设计周到具体全面
2009-11-11 13:08 TeDongDesiger
反方观点：
1，可以用触发器或应用程序保证数据的完整性
2，过分强调或者说使用主键／外键会平添开发难度，导致表过多等问题
3，不用外键时数据管理简单，操作方便，性能高（导入导出等操作，在insert, update, delete 数据的时候更快）
eg: 在海量的数据库中想都不要去想外键，试想，一个程序每天要insert数百万条记录，当存在外键约束的时候，每次要去扫描此记录是否合格，一般还不止一个字段有外键，这样扫描的数量是成级数的增长！我的一个程序入库在3个小时做完，如果加上外键，需要28个小时！
结论：
1，在大型系统中（性能要求不高，安全要求高），使用外键；在大型系统中（性能要求高，安全自己控制），不用外键；小系统随便，最好用外键。
2，用外键要适当，不能过分追求
3，不用外键而用程序控制数据一致性和完整性时，应该写一层来保证，然后个个应用通过这个层来访问数据库
在另一个社区IT-智库中讨论结果:
我先起个引子。
毫无疑问很多人都会对外键维护的复杂进行妥协，对它的性能产生怀疑，但在下一直固执的认为，外键就是系统完成性的一部分，不但要使用，而且要在符合语义环境的前提下尽量多的使用。
---------回复--------------
其实不然，完整性固然重要，但效率也非常重要，势必要在利用外键约束完整性与效率等因素之间寻求一个平衡点。
---------回复--------------
外键约束可以保障性能的完整性，而其他的业务逻辑也可以从一定程度上完成类似的功能；
反之，在某些情况下，不使用外键约束与使用外键约束，对某些业务逻辑的性能影响是很明显的。
---------回复--------------
严重支持钻钻，，，
---------回复--------------
偶以前做的一个项目就完全没有外皱起约束，需要关联约束的地方，全部由前台代码保证。
---------回复--------------
我个小屁孩也来说一句：
我觉得外键在很多情况下是必要的，它能让使用者少操很多心。
对于使用者来说，设计合理的外键能大大减低SQL语句的复杂性。
当然，如果外键的存在大幅降低了效率，或者让维护者无所适从的时候，也可以考虑使用其他方法保证完整性。
---------回复--------------
to : libin_ftsafe(子陌红尘：TS for Banking Card)
当然凡事得有度，我们可就这个度做一个衡量。
先说你提到的这一点吧，程序逻辑对数据完整性的检查和使用外键作为对数据完成性检查的优缺点。
---------回复--------------
外键多复杂谈不上，不过实际中的逻辑不可能象程序员要求的那样严格，所以还是少用
---------回复--------------
如果程序能做到很严谨，外键少，固然能提高数据库性能，但往往程序的严谨性很难保证，需要合理的平衡外键与性能的关系。
---------回复--------------
前台逻辑保证完整性采用的还是多的
---------回复--------------
需要关联约束的地方，全部由前台代码保证
-------------------------------------
这是很危险的，一个小小的bug或者一次误操作就可能使数据库中的数据违反业务逻辑。
---------回复--------------
相信到这个帖子来讨论的人，都是经历过不少系统设计工作的，今天拿这个很老套的问题出来讨论，就是想把很多问题量化、实例化，答疑解惑，分享经验，以怡后学。
---------回复--------------
to：wgzaaa
“实际中的逻辑不可能象程序员要求的那样严格” 说的很实在。
---------回复--------------
外键 我是经常用的，尤其是关系比较多的主表 与子表关系。
因为代码来维护这个感觉成本太高。
当然对于一些逻辑关系比较平淡的实体，可以忽略。
总之这东西不建议完全抛弃，毕竟是个好东西。
性能损失是有的，适当应用，我觉得挺好的
---------------------
确实如此，那个系统用长了就会产生一些垃圾数据，这些垃圾数据在前台永远都用不到，不过也不影响系统正常运转，，，
---------回复--------------
to： wangtiecheng(不知不为过，不学就是错！)
我试着量化一下吧，这里说到外键的性能，肯定就要涉及到索引的性能，是否可以这么说除了那些不断大量增加数据的表，包含大量历史数据表，要慎重考虑性能，而其它的那些表，则必须要考虑外键。
---------回复--------------
to fellowcheng(鹰击长空)
是否可以用异常来代替那些复杂的逻辑检查呢？
---------回复--------------
外键还是少用或者不用，在程序中判断就很好了
其实就我个人认为最重要的是在开发和测试阶段太多的外键，影响工作，降低效率
---------回复--------------
邹老大快出来讲讲啊
[quote]pinglexp： 支持楼主的言论 如果像后面的人所说的，要考虑性能，性能不是单单凭主键去优化的，而且等业务逻辑复杂的时候，单纯的主键也提高不了性能。 等你的数据量达到千万以上的级别的...
--安羽.
2. Re:数据库中主键和外键的设计原则
实践过博主说的主键自动生成对用户无意义,好处是从应用层面很多东西可以改,如部门表的部门编码(有实际意义),在组织结构变化比较大的情况也可以改.但坏处是开发维护以及平时思维被迫增加了很多麻烦,很多时候是...
--归来兮
3. Re:Visual Studio 2008 从头创建你的web站点
在看您的文章, 想学东西. 是否可以联系. 我的qq : 76542296 . msn : ehblan@hotmail.com 我接触asp.net 刚开始. 基本东西知道了需要看看类似您这样的实...
--hblan
4. Re:需求该如何分析？
当然是先梳理、描述清楚业务流程， 然后再分析、总结关键对象。 当然在梳理业务流程的时候要时刻有对象的观念。
--laoding
5. Re:数据库中主键和外键的设计原则
支持楼主的言论 如果像后面的人所说的，要考虑性能，性能不是单单凭主键去优化的，而且等业务逻辑复杂的时候，单纯的主键也提高不了性能。 等你的数据量达到千万以上的级别的时候，后期维护代价可想而知。 如...
--pinglexp
阅读排行榜
1. 数据库中主键和外键的设计原则 (9793)
2. 第一篇：使用Visual Studio 2008布局页面(9367)
3. 第六篇：ListView控件与DataPager控件详解（1）(9330)
4. Visual Studio 2008 从头创建你的web站点(6943)
5. 企业级开发的权限管理(4610)
评论排行榜
1. Visual Studio 2008 从头创建你的web站点(35)
2. 第一篇：使用Visual Studio 2008布局页面(35)
3. 企业级开发的权限管理(26)
4. 第六篇：ListView控件与DataPager控件详解（1）(21)
5. 是瀑布还是迭代敏捷（讨论）？(20)
数据库中主键和外键的设计原则
主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的设计对物理数据库的性能和可用性都有着决定性的影响。
必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。一旦将所设计的数据库用于了生产环境，就很难对这些键进行修改，所以在开发阶段就设计好主键和外键就是非常必要和值得的。
主键：
关系数据库依赖于主键---它是数据库物理模式的基石。主键在物理层面上只有两个用途：
1. 惟一地标识一行。
2. 作为一个可以被外键有效引用的对象。
基于以上这两个用途，下面给出了我在设计物理层面的主键时所遵循的一些原则：
1. 主键应当是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。
2. 主键应该是单列的，以便提高连接和筛选操作的效率。
注：使用复合键的人通常有两个理由为自己开脱，而这两个理由都是错误的。其一是主键应当具有实际意义，然而，让主键具有意义只不过是给人为地破坏数据库提供了方便。其二是利用这种方法可以在描述多对多关系的连接表中使用两个外部键来作为主键，我也反对这种做法，理由是：复合主键常常导致不良的外键，即当连接表成为另一个从表的主表，而依据上面的第二种方法成为这个表主键的一部分，然，这个表又有可能再成为其它从表的主表，其主键又有可能成了其它从表主键的一部分，如此传递下去，越靠后的从表，其主键将会包含越多的列了。
3. 永远也不要更新主键。实际上，因为主键除了惟一地标识一行之外，再没有其他的用途了，所以也就没有理由去对它更新。如果主键需要更新，则说明主键应对用户无意义的原则被违反了。
注：这项原则对于那些经常需要在数据转换或多数据库合并时进行数据整理的数据并不适用。
4. 主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等。
5. 主键应当有计算机自动生成。如果由人来对主键的创建进行干预，就会使它带有除了惟一标识一行以外的意义。一旦越过这个界限，就可能产生认为修改主键的动机，这样，这种系统用来链接记录行、管理记录行的关键手段就会落入不了解数据库设计的人的手中。
? 下一篇：企业级开发的权限管理
posted on 2008-04-02 13:02 tianyamoon 阅读(9793) 评论(13) 编辑 收藏 所属分类: 只是转载
FeedBack:
#1楼 2008-10-20 10:47 sciland[未注册用户]
很不错，希望与你直接交流，请你给我你的联系方式，如qq
回复 引用
#2楼 2009-01-22 13:36 NewSea.
1 。主键的第二个用途 是错误 的。
唯一索引 也可以作为外键被引用对象。
2。 主键原则第一条也是错误 的。导致第二条也是错误 的。
不知博主从哪里听说： 主键必须是无意义的。
主键在一些情况下，代表的是系统关系的联系对象。比如 公文ID ， 它对用户是无意义的，
而有一些情况下，比如人的身份证号 ， 或 省会编码。 可以用作主键。并且，它是有意义的。
综上所述。 博主之文章， 实在毫无意义。
回复 引用 查看
#3楼 2009-03-08 22:18 出cc[未注册用户]
良好的设计就是主键无意义
回复 引用
#4楼 2009-03-31 13:06 littlered[未注册用户]
--引用--------------------------------------------------
NewSea.:
2。 主键原则第一条也是错误 的。导致第二条也是错误 的。
不知博主从哪里听说： 主键必须是无意义的。
主键在一些情况下，代表的是系统关系的联系对象。比如 公文ID ， 它对用户是无意义的，
而有一些情况下，比如人的身份证号 ， 或 省会编码。 可以用作主键。并且，它是有意义的。
综上所述。 博主之文章， 实在毫无意义。
--------------------------------------------------------
身份证会升位的，省会会变直辖市的，这些的变更如果要影响到你所有的主键和外键，就是大工程了。
什么都不懂就乱鄙视你，真不知道应该笑你无知还是说你可悲
回复 引用
#5楼 2009-05-08 11:25 源声依旧
有一家帮助，集思广义
回复 引用 查看
#6楼 2009-05-09 01:09 qcrsoft[未注册用户]
"不知博主从哪里听说： 主键必须是无意义的"
——一定是要是听来的吗？相信是楼主从实践中总结来的
做了十年数据库设计，我的经验是主键的作用是唯一标识行数据，它不应当参与业务。除去楼主所说的一切外，还有一点很有说服力：前端代码好写
比如用身份证号做主键，假如身份证号录入错误（即使概率相当小系统也必须有要考虑）需要修改你需要做哪些工作？你需要首先修改各个用身份证做外键的表里的身份证号对吗？哎等等，新改正的身份证号在主表里还不存在，数据库不给你写那~~~先改主表里身份证号？主外键约束着也不给你改那，啊对，用级联更新，可是各个数据库对级联更新是有差异的哦
如果你编写WIN32的程序，你会发现comboBox、listbox们的value只能放数值，不能放字符，如果主键是字符，编码会需要曲线的把数据和控件绑定在一起
等等等等。。。。没有最好的，只用更好的，做的多了，你就会发现按楼主说的去做，至少你的代码写起来要舒服
劝NewSea多多实践，细心总结
回复 引用
#7楼 2009-06-11 18:57 ktstudio1[未注册用户]
我不是太同意楼主的观点。
原因如下：
我们应该在性能和可扩展性之间寻求平衡，而不是这种极端的做法。
如今的应用程序已不同于早期的只负责填写的简单程序，应用程序的更多任务是为需要从数据库中获取特定数据的人服务。不仅如此，我们的应用程序即使在提供一些简单功能时，往往也需要从一系列数据库主键中进行遍历，如果此时的数据记录主键没有任何业务特性，我们就不得不采用记录中的其他能够说明记录含义的字段来参与遍历，而这些字段甚至没有经过查询优化处理，更不要说跟主键的性能相比了。
事务独立性也非常重要。
事实上我们应该尽量将有意义的字段作为记录的主键，它不仅可以提高数据遍历的性能，在作为相关记录的外键时也更加有意义。
在有些开发者看来，他们从不考虑性能的因素。因为他们已习惯将性能指标交由硬件厂商。不幸的是，他们的应用程序也从不考虑高效的数据交换。
当他们开始交换数据时，他们一般都会说，这简直是要命的。因为他们的应用程序在宝贵的交换通道上传输着很多无意义的数据，因而也需要多个步骤才能完成整个过程。不幸的是，如果其中某个步骤出现异常，这个过程往往需要重来一遍。
我暂时说这么多。总之一句话，凡事不能太绝对。
作者的思想也能解决一些问题，不过只是在初期。当你再深入的时候，你就会发现，解决数据的关联性问题，只不是需要一种标准的手段，而且往往并不难，也有很多的可参考的标准和代码。这些问题迟早不再是你的问题。而你因为解决这些问题引入的固化思想可能是致命的。
回复 引用
#8楼 2009-06-24 15:25 slotbeta
同意LZ的说法，主键只用来唯一标识一行记录就OK，参与到业务中真是自找麻烦！虽然过去的时间很长了，但是不免说了这么句！
回复 引用 查看
#9楼 2009-08-13 20:09 Single[未注册用户]
引用
ktstudio1：我不是太同意楼主的观点。
<br/>原因如下：
<br/>我们应该在性能和可扩展性之间寻求平衡，而不是这种极端的做法。
<br/>如今的应用程序已不同于早期的只负责填写的简单程序，应用程序的更多任务是...
非常同意此种观点。
回复 引用
#10楼 2009-08-17 15:31 ben10303050[未注册用户]
我刚问了我的数据库老师，他说最好是有意义的，身份证还真是特例，身份证升位的话就停一下服务器，系统维护一下就好了，毕竟身份证升位是几十年才一次的。
身份证输错了的话，就先新增一条正确的身份证，然后改外键的那些表，最后删掉母表里面的错误的那一条就行了。
回复 引用
#11楼 2009-12-15 15:13 pinglexp[未注册用户]
支持楼主的言论
如果像后面的人所说的，要考虑性能，性能不是单单凭主键去优化的，而且等业务逻辑复杂的时候，单纯的主键也提高不了性能。
等你的数据量达到千万以上的级别的时候，后期维护代价可想而知。
如果你是小系统，那是无所谓，哈哈，想怎么怎么的。
回复 引用
#12楼 2010-06-25 10:44 归来兮
实践过博主说的主键自动生成对用户无意义,好处是从应用层面很多东西可以改,如部门表的部门编码(有实际意义),在组织结构变化比较大的情况也可以改.但坏处是开发维护以及平时思维被迫增加了很多麻烦,很多时候是没必要的. 不同意把这个原则绝对化,博主太武断了.
回复 引用 查看
#13楼 2010-10-31 15:10 安羽.
引用
pinglexp：
支持楼主的言论
如果像后面的人所说的，要考虑性能，性能不是单单凭主键去优化的，而且等业务逻辑复杂的时候，单纯的主键也提高不了性能。
等你的数据量达到千万以上的级别的时候，后期维护代价可想而知。
如果你是小系统，那是无所谓，哈哈，想怎么怎么的。
支持楼主、支持pinglexp，不要为性能（或其它方面）找借口，设计本源是为了好用、实用、简单化（易用）（荐＜软件开发的科学与艺术＞的软件设计之源部分），数据库设计的性能指标只是综合性能指标的一部分，优化性能方式有好多方案，就微软自己总结出来的：与其花数周或数月时间与人力做设计、算法的优化才提高百分之十几性能，不如新买一个最新的中等价格多核服务器提高50％～200％的性能来的有效。（当然我也不反对优化，优化还是很重要的）数据库中主键用表视角代表一行唯一的数据，用ER关系视角（表是实体模板）行是一个实体的实例，用面象对象的视角是一个可确定对象。这样看来主键可以有意义也可以无意义，有意义时主键对于对象（或实体、行）的是有一个有意义属性，无意义时主键的属性只有一个意义就标识对象。我想楼主有目的把主键主动设计为无意义认为是好的设计这也无可厚非，从设计本源这样没错（我也是这样实践的），因为无论从哪种视角主键唯一标识的特性是不变的，这是行、实体、对象的根基，标识不变说明对象（行、实体）是确定的，再去访问修改属性都会简单易行。把事件复杂化、讲什么大理论，把问题搞的玄而又玄，不是什么好设计，设计的目的是为了：简。
没有放之四海而皆准的真理，真理是有条件的。
＠NewSea
"唯一索引 也可以作为外键被引用对象。"也不能说明：“主键作为一个可以被外键有效引用的对象。 “是错误的。你都说”也可以“了，为什么还说人家是错的。
******************************************************************************************************************************************************
数据库建模外键大讨论(1)
来自乱世经典
最近在做一个派单系统数据库设计，在设计中有些疑惑的地方中午在网上发起一个话题讨论. 我把这个讨论流程.发过来 大家可以可以看看.
也可以发表一下自己的意见.
对于主/外键/索引来说，在一些开发团队中被认为是处理数据库关系的利器，也被某些开发团队认为是处理某些具体业务的魔鬼，您的观点呢？在实际应用中您会采取哪种方式？
大家共同观点：
主键和索引是不可少的，不仅可以优化数据检索速度，开发人员还省不其它的工作,
矛盾焦点：数据库设计是否需要外键。这里有两个问题：一个是如何保证数据库数据的完整性和一致性；二是第一条对性能的影响
2009-11-11 13:07 changShaHacker
正方观点：
1，由数据库自身保证数据一致性，完整性，更可靠，因为程序很难100％保证数据的完整性，而用外键即使在数据库服务器当机或者出现其他问题的时候，也能够最大限度的保证数据的一致性和完整性。
eg：数据库和应用是一对多的关系，Ａ应用会维护他那部分数据的完整性，系统一变大时，增加了Ｂ应用，Ａ和Ｂ两个应用也许是不同的开发团队来做的。他们如何协调保证数据的完整性，而且一年以后如果又增加了C应用呢？
2，有主外键的数据库设计可以增加ER图的可读性，这点在数据库设计时非常重要。
3，外键在一定程度上说明的业务逻辑，会使设计周到具体全面
2009-11-11 13:08 TeDongDesiger
反方观点：
1，可以用触发器或应用程序保证数据的完整性
2，过分强调或者说使用主键／外键会平添开发难度，导致表过多等问题
3，不用外键时数据管理简单，操作方便，性能高（导入导出等操作，在insert, update, delete 数据的时候更快）
eg: 在海量的数据库中想都不要去想外键，试想，一个程序每天要insert数百万条记录，当存在外键约束的时候，每次要去扫描此记录是否合格，一般还不止一个字段有外键，这样扫描的数量是成级数的增长！我的一个程序入库在3个小时做完，如果加上外键，需要28个小时！
结论：
1，在大型系统中（性能要求不高，安全要求高），使用外键；在大型系统中（性能要求高，安全自己控制），不用外键；小系统随便，最好用外键。
2，用外键要适当，不能过分追求
3，不用外键而用程序控制数据一致性和完整性时，应该写一层来保证，然后个个应用通过这个层来访问数据库
在另一个社区IT-智库中讨论结果:
我先起个引子。
毫无疑问很多人都会对外键维护的复杂进行妥协，对它的性能产生怀疑，但在下一直固执的认为，外键就是系统完成性的一部分，不但要使用，而且要在符合语义环境的前提下尽量多的使用。
---------回复--------------
其实不然，完整性固然重要，但效率也非常重要，势必要在利用外键约束完整性与效率等因素之间寻求一个平衡点。
---------回复--------------
外键约束可以保障性能的完整性，而其他的业务逻辑也可以从一定程度上完成类似的功能；
反之，在某些情况下，不使用外键约束与使用外键约束，对某些业务逻辑的性能影响是很明显的。
---------回复--------------
严重支持钻钻，，，
---------回复--------------
偶以前做的一个项目就完全没有外皱起约束，需要关联约束的地方，全部由前台代码保证。
---------回复--------------
我个小屁孩也来说一句：
我觉得外键在很多情况下是必要的，它能让使用者少操很多心。
对于使用者来说，设计合理的外键能大大减低SQL语句的复杂性。
当然，如果外键的存在大幅降低了效率，或者让维护者无所适从的时候，也可以考虑使用其他方法保证完整性。
---------回复--------------
to : libin_ftsafe(子陌红尘：TS for Banking Card)
当然凡事得有度，我们可就这个度做一个衡量。
先说你提到的这一点吧，程序逻辑对数据完整性的检查和使用外键作为对数据完成性检查的优缺点。
---------回复--------------
外键多复杂谈不上，不过实际中的逻辑不可能象程序员要求的那样严格，所以还是少用
---------回复--------------
如果程序能做到很严谨，外键少，固然能提高数据库性能，但往往程序的严谨性很难保证，需要合理的平衡外键与性能的关系。
---------回复--------------
前台逻辑保证完整性采用的还是多的
---------回复--------------
需要关联约束的地方，全部由前台代码保证
-------------------------------------
这是很危险的，一个小小的bug或者一次误操作就可能使数据库中的数据违反业务逻辑。
---------回复--------------
相信到这个帖子来讨论的人，都是经历过不少系统设计工作的，今天拿这个很老套的问题出来讨论，就是想把很多问题量化、实例化，答疑解惑，分享经验，以怡后学。
---------回复--------------
to：wgzaaa
“实际中的逻辑不可能象程序员要求的那样严格” 说的很实在。
---------回复--------------
外键 我是经常用的，尤其是关系比较多的主表 与子表关系。
因为代码来维护这个感觉成本太高。
当然对于一些逻辑关系比较平淡的实体，可以忽略。
总之这东西不建议完全抛弃，毕竟是个好东西。
性能损失是有的，适当应用，我觉得挺好的
---------------------
确实如此，那个系统用长了就会产生一些垃圾数据，这些垃圾数据在前台永远都用不到，不过也不影响系统正常运转，，，
---------回复--------------
to： wangtiecheng(不知不为过，不学就是错！)
我试着量化一下吧，这里说到外键的性能，肯定就要涉及到索引的性能，是否可以这么说除了那些不断大量增加数据的表，包含大量历史数据表，要慎重考虑性能，而其它的那些表，则必须要考虑外键。
---------回复--------------
to fellowcheng(鹰击长空)
是否可以用异常来代替那些复杂的逻辑检查呢？
---------回复--------------
外键还是少用或者不用，在程序中判断就很好了
其实就我个人认为最重要的是在开发和测试阶段太多的外键，影响工作，降低效率
---------回复--------------
邹老大快出来讲讲啊
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
