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

那就自己写SQL，用JDBC来实现吧。

我设计的数据库的时候，画ER图还是要加上外键等，看着舒服，然后在前期开发时候可能把关联去掉，功能开发到中后期，我一般都会把关联加上，并且保持和上线时候一致。因为数据库完整性的测试也应该是测试的一个重要部分，如果没有关联，这部分怎么保证？ 可能在功能测试方面很难注意到方方面面的事。前面有人讲关联会影响性能，这个我倒是没有想过。不知道谁能给出具体的测试数据？

毫无疑问，数据库建了关联，保持数据的完整性，这是非常必要的。

至于说会导致性能问题，那完全是使用Hibernate不够优化而导致的。POJO中建多了一对多，多对对的关联关系，你看看Hibernate执行的SQL就能知道，JOIN了那么多的表，不慢才怪。

我的倾向是对于小数据字典表的操作用程序自动关联，业务逻辑表的关联，尽量手工去做。如果性能还是有问题，那就再减少程序关联。

遗留系统，关联不关联你说了不算。
新系统，用hibernate的话先考虑表的问题岂不是跑偏了

实际上这我觉得还得看实际的系统，关系数据库就不一定非得用到关系，你可以以代码的方式去处理。数据量一但上去之后用join去查询你会觉得很痛苦

很多人都强调数据完整性，但是现实世界是数据往往要容错的，而且完整性并不是要同一时间保证的，比如你填一份表格，有几个栏位不确定，但是已经填的需要放入，没填的等明确了再填，但是数据库约束却认为这份数据是不合法的，无法加入，岂不是很不好的体验。数据完整性现实世界操作往往不是同一时间完成的，但是电脑却蛮横无理要求一定要满足了才能放入，是很糟糕的体验。

都不关联了，还用hibernate吗？

能保证数据完整性即可 连不连都行

   一般而言，数据库关联不关联也取决于具体的项目，如果来来回回就那么几张表，那关联也无所谓；如果是大型ERP系统，需要1W以上的表单的话，那是不能关联的，因为即使关联也无人知道ER图之类的。
   数据库关联是解决数据完整性的简单方式，但并非只有关联才能解决数据库完整性。因而，LS说的正确，能保证数据完整性，关不关联无所谓。

除了极端性能要求的情况下，外键是不嫌多的。
大部分的应用，读多写少，外键的性能影响几乎可以忽略，只要索引合适就行。

通常软件开发经验越丰富，越是会知道关联/外键的好处。

应用层的校验不可靠的，外键就是为了防止应用层逻辑的不可靠。