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

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

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

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

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

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

关系数据库当然要建关联，2NF总是要的。不然极有可能出现错误数据，如员工所属的部门，在部门信息表中不存在，这会导致程序出错。当然你可以增加判断，但太麻烦了，用了关联，数据库就可以帮你解决掉这个问题。

至于关联会影响性能的问题，你难道做的是数据仓库？

在hibernate配置中也建议用关联，因为没有关联，hql的外连接是不行的。而且代码可以更OO。

关联不关联这个是设计问题吧，跟性能无关，如果你表可以设计得不关联，那完全ok的。但是该关联的还是要关联的啊。至于性能：hibernate里面对应不是有个fetch的设定的么，设成lazy的话，如果不用到的话就不会去取关联的值，不会有性能损失啊。可以看一下debug打出来的sql。

当然关联啊

hibernate能做的,而且做的还挺好的.
想不出非要自己重复制造轮子的理由.
我相信多数情况下,我们程序员的代码并不比hibernate更好.
除非你的某个设计目的就是朝着它的死穴去的.

大项目： 数据量大 交易频繁 。。 还是建议不关联。在代码中使用事务来保证数据。
我觉得 DBA也不会建议太多关联。 有时候函数也不让用。 索引不让随便加。 触发器更是不用想了。

中小型的 可以加上关联。