对主键/外键/索引来说，有些开发团队认为是处理数据库关系的利器，有些开发团队认为是处理特定业务的恶魔，你的想法是什么？ 在实际的APP中采取什么样的方法？
大家共同的观点：
主键和索引是必不可少的，不仅可以优化数据的搜索速度，还可以让开发人员省去其他工作。
矛盾：数据库设计是否需要外键。 这里有两个问题。 一是如何保证数据库数据的完整性和一致性；二是对第一个性能的影响。
正面看法：
1 )数据库本身保证数据的完整性、完整性、更可靠。 虽然程序难以100%保证数据的完整性，但是使用外键可以最大限度地保证数据的完整性和完整性，即使在数据库服务器崩溃或出现其他问题时也是如此。
()数据库和APP是一对多的关系，a APP应用维护他的数据的完整性。 系统变大后，会追加b APP应用，a和b两个APP应用可能是不同的开发团队做的。 如果他们如何协调以保证数据的完整性，一年后添加c APP，会怎么样？
2 )具有主外键的数据库设计可以提高ER图的可读性，这在数据库设计时非常重要。
3 )外键在某种程度上说明的业务逻辑，使设计周全且具体全面。
另一方面的观点：
1 )可以通过触发器和APP来保证数据的完整性。
2 )如果过分强调或使用主键/外键，则会产生开发困难、表过多等问题。
3 )不使用外键时，数据管理简单、操作简单、性能高(insert、update、delete数据的导入导出等操作更快)。
eg:请勿在庞大的数据库中考虑外键。 想想一个每天插入数百万张记录的程序。 如果有外键约束，则每次扫描该记录是否通过时，多个字段通常都有外键。 这样，扫描次数呈级数增长。 我的程序入住三个小时就结束了。 加上外键，需要28个小时！
结论：
1 )在大型系统中)使用外键(性能要求不高，安全要求高)； 在大型系统中，(性能要求高，可以安全地自己控制)不使用外键； 小系统是自由的，最好使用外键。
2 )使用外键是合适的，不要过分追求。
3 )如果不使用外键，通过编程控制数据的完整性和完整性，则需要编写一个层以保证，然后每个APP都需要通过该层访问数据库。
最后说两句，其实外键这东西不好，不能用，这种认识也并不错误。 如果只是没有外键约束，那么可以随心所欲地写SQL，包括徒手修理数据时不受约束，反而是本末倒置的做法。 为了追求这样的便利，关系型数据库不应该失去提供的重要保障。
最后一次
有意思的是，查了一些资料，国内一色支持不使用外键，国外推荐使用外键……但是，国外并不是不允许使用外键进行insert开销，大部分情况下是忽略的另外，我认为关系数据库的核心功能其实是关系和事务。 关于数据的完整性、一致性，使用它。