数据库的设计原则：关联还是不关联？
数据库的设计原则：关联还是不关联？
设计网站数据库（确定使用Hibernate）的过程中，时常会有争论，争论的焦点主要还是集中在表与表之间的关联上面：
有的倾向于去掉表与表之间的任何关联；有的拿完整性说话，必须保留所有的关联性。
先说我的观点：我倾向于去掉所有的关联，为了开发的方便。然后写代码的时候自己留意完整性的问题。 45 楼 murainwood 2009-10-20 Hibernate 自动生成的 SQL，只能算是合格。SQL毕竟是和数据库相关的。有时候一句SQL，得去想想数据库里到底发生了什么 46 楼 putonyuer 2009-10-20 xinshaoye 写道网站数据库设计 多采用反范式设计
除了开发的方便 也还考虑到访问量问题 个人倾向于少关联
是啊 ， 这个主要看什么系统， 如果是给党国的办公系统， 根本不用考虑这些。
如果是实用性的 ， 关键表 确实得冗余少关联。
47 楼 ycysth 2009-11-04 作为一个初学者，现在确实感觉不到关联的好处，而且感觉很麻烦 48 楼 ngr1984 2009-11-04 工作时间不长,个人感觉关联对于开发人员来讲是一个很麻烦的问题,一般不考虑关联. 49 楼 clockmaker 2009-11-04 qaz1234 写道hibernate能做的,而且做的还挺好的.
想不出非要自己重复制造轮子的理由.
我相信多数情况下,我们程序员的代码并不比hibernate更好.
除非你的某个设计目的就是朝着它的死穴去的.
奇怪的论调，别人造的轮子不转，难道自己还得等人家造会转的轮子？ 50 楼 clockmaker 2009-11-04 fangzhouxing 写道【我们项目的关联（一般来说就是FK）都是在应用级别做逻辑关联的，在数据库级别没有做】
严重同意这种做法，hibernate的关联写法和用法是编程中的难点。
那就自己写SQL，用JDBC来实现吧。 51 楼 grandboy 2009-11-04 我设计的数据库的时候，画ER图还是要加上外键等，看着舒服，然后在前期开发时候可能把关联去掉，功能开发到中后期，我一般都会把关联加上，并且保持和上线时候一致。因为数据库完整性的测试也应该是测试的一个重要部分，如果没有关联，这部分怎么保证？ 可能在功能测试方面很难注意到方方面面的事。前面有人讲关联会影响性能，这个我倒是没有想过。不知道谁能给出具体的测试数据？ 52 楼 zzhonghe 2009-11-07 毫无疑问，数据库建了关联，保持数据的完整性，这是非常必要的。
至于说会导致性能问题，那完全是使用Hibernate不够优化而导致的。POJO中建多了一对多，多对对的关联关系，你看看Hibernate执行的SQL就能知道，JOIN了那么多的表，不慢才怪。
我的倾向是对于小数据字典表的操作用程序自动关联，业务逻辑表的关联，尽量手工去做。如果性能还是有问题，那就再减少程序关联。 53 楼 helian 2009-11-08 遗留系统，关联不关联你说了不算。
新系统，用hibernate的话先考虑表的问题岂不是跑偏了 54 楼 bluemaple 2009-11-08 bluemeteor 写道关系数据库..不关联为什么用关系数据库？
你应该慎重抉择hibernate中的one-to-many和many-to-many的使用，但是库表上的关系必须要声明
实际上这我觉得还得看实际的系统，关系数据库就不一定非得用到关系，你可以以代码的方式去处理。数据量一但上去之后用join去查询你会觉得很痛苦 55 楼 carlkkx 2009-11-08 很多人都强调数据完整性，但是现实世界是数据往往要容错的，而且完整性并不是要同一时间保证的，比如你填一份表格，有几个栏位不确定，但是已经填的需要放入，没填的等明确了再填，但是数据库约束却认为这份数据是不合法的，无法加入，岂不是很不好的体验。数据完整性现实世界操作往往不是同一时间完成的，但是电脑却蛮横无理要求一定要满足了才能放入，是很糟糕的体验。 56 楼 vager 2009-11-08 都不关联了，还用hibernate吗？ 57 楼 jcs7575 2009-11-08 能保证数据完整性即可 连不连都行 58 楼 JackAndroid 2009-11-09 一般而言，数据库关联不关联也取决于具体的项目，如果来来回回就那么几张表，那关联也无所谓；如果是大型ERP系统，需要1W以上的表单的话，那是不能关联的，因为即使关联也无人知道ER图之类的。
数据库关联是解决数据完整性的简单方式，但并非只有关联才能解决数据库完整性。因而，LS说的正确，能保证数据完整性，关不关联无所谓。 59 楼 jasonshi 2009-11-09 除了极端性能要求的情况下，外键是不嫌多的。
大部分的应用，读多写少，外键的性能影响几乎可以忽略，只要索引合适就行。
通常软件开发经验越丰富，越是会知道关联/外键的好处。
应用层的校验不可靠的，外键就是为了防止应用层逻辑的不可靠。
60 楼 zhangzhongde 2009-12-07 我建议您还是不要关联 自己用自己的业务逻辑比较好 61 楼 daizz 2009-12-09 开发经验丰不丰富也没啥关系吧
应用层逻辑不可靠，测试难道不能测出来么
ls有个哥们说得好，自己有把握就自己处理关联关系，没把握就用数据库
jasonshi 写道除了极端性能要求的情况下，外键是不嫌多的。
大部分的应用，读多写少，外键的性能影响几乎可以忽略，只要索引合适就行。
通常软件开发经验越丰富，越是会知道关联/外键的好处。
应用层的校验不可靠的，外键就是为了防止应用层逻辑的不可靠。
62 楼 iamlotus 2009-12-14 carlkkx 写道很多人都强调数据完整性，但是现实世界是数据往往要容错的，而且完整性并不是要同一时间保证的，比如你填一份表格，有几个栏位不确定，但是已经填的需要放入，没填的等明确了再填，但是数据库约束却认为这份数据是不合法的，无法加入，岂不是很不好的体验。数据完整性现实世界操作往往不是同一时间完成的，但是电脑却蛮横无理要求一定要满足了才能放入，是很糟糕的体验。
这是最不负责任的作法。分析时不管业务意义上的约束，而是放开所有约束。等到生产环境出现了脏数据，一句“用户使用不规范”就给打发了。 63 楼 SoloT 2009-12-15 iamlotus 写道carlkkx 写道很多人都强调数据完整性，但是现实世界是数据往往要容错的，而且完整性并不是要同一时间保证的，比如你填一份表格，有几个栏位不确定，但是已经填的需要放入，没填的等明确了再填，但是数据库约束却认为这份数据是不合法的，无法加入，岂不是很不好的体验。数据完整性现实世界操作往往不是同一时间完成的，但是电脑却蛮横无理要求一定要满足了才能放入，是很糟糕的体验。
这是最不负责任的作法。分析时不管业务意义上的约束，而是放开所有约束。等到生产环境出现了脏数据，一句“用户使用不规范”就给打发了。
你给党国的某些部门做事儿，约束性太强了，那些人还以为你的系统有问题呢 64 楼 steeven 2009-12-15 大家的case都不大一样, 结论自然不同.
偶是做c/s的, 数据要在远程传递, lazy的话序列化和jaxb都会有问题. 不lazy效率不高. 做b/s的可能没这个问题.
另外, 我觉得hibernate validation框架应该解决这个问题. 加上一个@FK属性就行了, 不要总干些拔出萝卜带出泥的事情.
另外, 强壮的系统似乎不应该依靠关联来检查错误, 就是报错信息也不好看.
查询效率问题, 冗余啊, 视图啊, 缓存啊都可以, 看数据量,效率了
偶准备做个POJO driven framework, 这个关联准备交给框架处理, 不要在数据库层面折腾.
