问题描述
最近参加了一个的较大型的项目，发现pdm里面没有表与表的关系，仔细研究了一下，貌似全部关系是靠代码控制的，在库级别没有建立任何关系，突然发现这样做也挺不错的。问问大大们，数据库建立关系与不建立关系各有什么优缺点啊
解决方案
首先说一点，使用外键是为什么？外键的使用时为了在数据库的层级保证数据的一致性，完整性，更可靠。毕竟使用程序来控制的话，对于程序员的要求是比较高的。然后再说应用场景：追求的数据的完整性等，那就用上外键吧。毕竟不可控的因素太多了，还不如让数据库自己来保证。如果数据库都保证不了，那就game over啦。 追求性能，而且是在大数据量的频繁更新操作下。那就让外键去见鬼吧，这个时候外键还存在，不是完全的捣蛋吗？插入一条数据由于外键的存在还要去做一次一致性约束检测，这不是在浪费时间吗？所以在这种条件下，外键就有点不太实用了。当然你的数据量不大，那么你使用外键是没有问题的（数据量不大也不需要考虑高速写入的问题了 ）所以说，这是一个权衡，看你用想要什么。参考：http://www.dewen.org/q/1814/mysql+%E5%A4%96%E9%94%AE%E9%97%AE%E9%A2%98题外话：如果你要高速写入大数据量，就不要用关系型数据库了，这个解决起来有点麻烦。现在不是NOSQL很火吗，看看这个吧。呵呵
解决方案二：
以前看过有人对这方面的一些说法，内容大概是这样。数据库建模时，应尽可能的实现相关的规范，比如多少范式之类的，使其完整性更完整些。（言下之意：外键什么的还是加上的）。当程序完成后，再把外键之类的约束删除（如果是数据库方面出现性能瓶颈的话），直接由代码控制。我倒觉得其实二种情况都挺符合实际的，只是看场景了。但有一样东西是最明显的，就是维护的成本。我只知道如果我接手一个系统，一打开数据库啥关系也看不到，那我觉得很痛苦在。
解决方案三：
建议不要用外建，容易出现n+1问题
解决方案四：
外键关系，我觉得大多数可以不建立。 可以最近的一个项目中，部门老大的习惯就是必须要建立外键关系。 说什么 这样数据可以随便删除，导致一些垃圾数据。 靠，生产环境上，谁去删数据啊。况且我们系统中做的都是软删除，除非客户的db去删数据，
解决方案五：
一般都不在数据库上建立主外键关系，都在代码里维护了！建在数据库里面在做数据麻烦，而且后期建索引的时候也有影响。
解决方案六：
个人建议数据中各表之间还是需要适当的主外键关系的，之前我进公司接手的是个二手项目，一年前搭建的，我们是在上面做二次开发，就是各表之间就没有相应的关系约束，很难维护，而且有大量的冗余数据。现在公司又做了几个项目，我们都是创建好各表之间主外键关系，这样结构清晰，数据关系清楚，容易维护。
解决方案七：
楼主说的是表与表之前并没有建立实际的外键关联吧，个人觉得外键关联实际的作用不大，反而会给操作数据带来阻碍。靠应用里边的领域模型来维护这些关系就显得更加的灵活。现在的数据库的主要作用还是在于存储这一单一功能，尽量不要使得数据库数据之间的规则变得复杂，能简单就简单吧。
解决方案八：
代码量大，如果关系复杂的话，维护代价高。pdm中不能直观的程现表与表之间的关系，只能靠读文档了解，很不方便如果直接对数据库操作很容易误删数据等
解决方案九：
和用泛型和不用泛型一样