数据库的设计原则：关联还是不关联？

数据库的设计原则：关联还是不关联？

设计网站数据库（确定使用Hibernate）的过程中，时常会有争论，争论的焦点主要还是集中在表与表之间的关联上面：
有的倾向于去掉表与表之间的任何关联；有的拿完整性说话，必须保留所有的关联性。


先说我的观点：我倾向于去掉所有的关联，为了开发的方便。然后写代码的时候自己留意完整性的问题。

评论

24 楼 zhongxuchen 2009-03-25  

这种问题需要具体问题具体分析，业务表必须要关联，但要主意关联的度，多重关联时要注意在合适的地方切断，不是为了关联而关联，更不能一刀切全不关联，oracle erp中都有关联呢，一两万张表，记得刚毕业那年一开始就让我去做erp报表，没有人告诉我需要用到哪几张表，靠要是没有关联以及表命名的合理性还不搞死，所以现在看到表命名不规范的就极其鄙视（尤其表命名用中文拼音简写的，直接否定为垃圾，其它再牛也算垃圾，后期维护简直就是一个深渊，更见过表全用中文定义的（这样的人就不应该搞编程，不是崇洋媚外，中文就是一个痛苦呀，乱码什么的，说实话也不美观），），个人认为是一个度的把握，这完全要凭经验了，不可一刀切！

23 楼 pacocai 2009-03-15  

事实上最初我也较为倾向于不关联，所有的验证可以在开发的时候去实现，但是和一位老前辈讨论了一下，得到这样的一种说法，如果对于数据量大的处理的时候，关联除了能保证数据的完整性外，还有利于提高数据检索的效率，假定数据量在一千万的情况下，两个表都设定了索引，在实际的查询过程中，有关联的效率要高于无关联的效率。具体我没测试过。

22 楼 魔力猫咪 2009-03-15  

建议进行关联。那些所谓的什么为了性能什么范式也不管的话不过是他自己数据库能力不过关罢了。
很多时候所谓的“按照范式速度太慢”其实不过是SQL写得太差而已。还有就是索引使用不合理，造成性能损失。索引不是随便乱加的，每加一个，造成的CUD性能损失可不小。
建议你看看《SQL语言艺术》这本书。你每一个冗余都就会造成数据维护困难，备份占地方，恢复速度变慢等问题。
而且你可以通过各种缓存进行缓冲，现在很多人特别是一些以前的开发人员，特别爱吃老本，对缓存及其不信任，什么都想存数据库里，什么都直接从那里读。很多复杂的查询对时间的有效性都是不太敏感的，完全可以使用缓存来减轻压力。

21 楼 leobluewing 2009-03-15  

不关联？ 很多实时查询的统计要死人的，本来查个子表就解决的问题，一定要去查大表了。

20 楼 lwx_1987 2009-03-06  

关联不关联还是得根据具体的业务具体分析，系统压力过大，为了避免影响性能，建议还是不关联的好！

19 楼 julycool 2009-02-22  

具体问题具体分析了，就像表设计中打破范式一样，先范式设计表，再打破范式。不用关联将数据冗余到一张表中,在数据量大的时候自然要比关联的快,但占用的物理空间肯定要大些。

18 楼 greencoffee 2009-02-18  

基本不考虑关联

17 楼 yyjn12 2009-02-18  

sdh5724 写道

看你做什么样一个压力的系统了， 如果的系统是每秒要上万个交易的话， 亲爱的， 我建议你少用join吧。少于１Ｗ／Ｓ的系统，　无所谓，　怎么搞都一样的。　完整性比任何都重要，　在压力过高的时候，　妥协而已！　　我的策略就是对于主压力的表，　一般来说，　系统中总是有几个焦点表的，　数据访问压力高，　读写密集的，　这个几个表好好设计，　不要关联，把读写操作让能力好的，　经验丰富的程序员去做封装ＤＡＯ　ＡＰＩ。　其他的小表，　要做关联，　防止程序员出问题。

每秒9000个交易的话，“无所谓，　怎么搞都一样的。”？
牛
我还停留在每秒几百个交易的阶段..

16 楼 tessyang 2009-02-18  

楼上的说法 很令人费解 你测试不包含测关联性的吗 测试时没有关联性那你测试还有什么用？

15 楼 winstonczc 2009-02-18  

现在做项目在设计时会考虑关联，特别是一些业务上关系紧密的数据
开发、测试时没有关联，等项目第一次完整测试后，再加上关联

14 楼 xinshaoye 2009-01-10  

网站数据库设计 多采用反范式设计
除了开发的方便 也还考虑到访问量问题 个人倾向于少关联

13 楼 bizzad 2009-01-07  

打倒小日本 写道

完全关联 完全不关联都不好
过犹不及 中庸才是正途
结论就是：
尽量关联 不关联是作为关联的特例 而不是常态

特例？我倒觉得关联应该是特例

12 楼 阳光晒晒 2009-01-07  

sdh5724 写道

看你做什么样一个压力的系统了， 如果的系统是每秒要上万个交易的话， 亲爱的， 我建议你少用join吧。少于１Ｗ／Ｓ的系统，　无所谓，　怎么搞都一样的。　完整性比任何都重要，　在压力过高的时候，　妥协而已！　　我的策略就是对于主压力的表，　一般来说，　系统中总是有几个焦点表的，　数据访问压力高，　读写密集的，　这个几个表好好设计，　不要关联，把读写操作让能力好的，　经验丰富的程序员去做封装ＤＡＯ　ＡＰＩ。　其他的小表，　要做关联，　防止程序员出问题。

对于变态的性能需求.
与人类理解力的需求.

这对矛盾,有很大的分歧

对于理解方便来说,当然不关联好一些....因为大多数代码里已经有了关联....
对于数据完整性来说,(安全性的一种)当然是放在数据里更好...

性能问题不考虑,.

所以说这个问题是指数据关联是放在代码里好还是放在数据里好的问题.
从开发角度来讲放代码里好开发
从维护角度来讲放数据里可以保护数据,可以把约束传递给下一个系统.
但从现实角度,往往性能问题才是最关键的......(因为建表的人一般都是DBA)

11 楼 打倒小日本 2009-01-07  

完全关联 完全不关联都不好
过犹不及 中庸才是正途
结论就是：
尽量关联 不关联是作为关联的特例 而不是常态

10 楼 johnnyhg 2009-01-07  

bizzad 写道

我们现在这个做了4年还在做，200m，50多万行的项目现在是倾向于完全不建关联了，新的数据模型一律不考虑关联

楼上能详细说说吗？

9 楼 bizzad 2009-01-06  

我们现在这个做了4年还在做，200m，50多万行的项目现在是倾向于完全不建关联了，新的数据模型一律不考虑关联

8 楼 bluemeteor 2009-01-06  

关系数据库..不关联为什么用关系数据库？

你应该慎重抉择hibernate中的one-to-many和many-to-many的使用，但是库表上的关系必须要声明

7 楼 only_java 2009-01-06  

为什么在压力过高的时候不用关联啊？难道还会影响性能？

6 楼 sdh5724 2008-12-16  

看你做什么样一个压力的系统了， 如果的系统是每秒要上万个交易的话， 亲爱的， 我建议你少用join吧。少于１Ｗ／Ｓ的系统，　无所谓，　怎么搞都一样的。　完整性比任何都重要，　在压力过高的时候，　妥协而已！　　我的策略就是对于主压力的表，　一般来说，　系统中总是有几个焦点表的，　数据访问压力高，　读写密集的，　这个几个表好好设计，　不要关联，把读写操作让能力好的，　经验丰富的程序员去做封装ＤＡＯ　ＡＰＩ。　其他的小表，　要做关联，　防止程序员出问题。

5 楼 hyxw5890 2008-12-16  

    如果不采用外键关联的话，很多字段势必得集中在一个表里面，从而造成数据冗余。根据领域模型驱动的方式设计数据库表结构，领域模型中的每一个对象只有一项职责，所以对象中的数据项不存在传递依赖，这种思路的数据库表结构设计从一开始即满足第三范式：一个表应满足第二范式，且属性间不存在传递依赖。
    如果是小项目的话，为了开发方便一点而不关联都问题不大，但要是大项目的话，感觉还是遵守规范的好