很抱歉以假名发布，但由于公司限制我必须保持匿名，并且通常是为了保护无辜者。
我已经做了大约18年的专业开发人员，虽然我不是一名DBA，但多年来我一直与他们密切合作，并形成了我认为对于什么是好的和不好的感觉数据库实践。我刚刚加入了一个公司，两个开发人员负责数据库模式，我发现他们非常反对使用外键约束。
他们最好的理由就是这样 （1）由于涉及额外的数据设置，它使单元测试存储过程更加困难 （2）外键可能会因顺序重要而引发错误。他们实际上更喜欢孤立的数据，而不是停止应用程序。
这对我来说似乎是不好的做法，但他们坚定不移。我们提出了外键在数据完整性，查询性能，生成数据库图表等方面提供的优势，但无济于事。
我在这里看不到什么？有什么建议？
答案 0 :(得分：7)
如果你所描述的是真正的开发者，我认为他们是被误导或天真的。外键的一般方法。当然，很有可能有充分的理由说明为什么外键约束不能或不应该应用于任何给定系统中的某些特定属性。也许这就是明显的修辞背后的真正原因。
我的建议。如果您是相关系统的利益相关者，那么请不要与开发人员交谈，与开发经理或拥有该系统的任何人交谈。通过具体示例来支持您的案例，其中缺乏参照完整性会产生负面影响或构成未来风险。
如果您没有当前与RI相关的问题，那么您可能主要关注的是改进未来工作的政策或发展方法。与数据库经理，DBA或负责标准和信息风险的人员交谈。考虑为开发团队的利益投资一些培训，指导或咨询。
答案 1 :(得分：-3)
我一直在设计数据库系统超过30年。这是我的看法 - 你可能不会喜欢它。在设计关闭系统时，您的参照完整性可能会内置到应用程序的用户界面中。您只能添加需要Color的Product实体记录 - 由用户界面强制执行。那为什么要有外键呢？我不做打开数据库，任何人都可以做任何事情 - 所以你的典型后端将有数千行前端代码保护数据的完整性。外键上的螺栓只是挡住了，并没有为您提供任何真正的服务。它不像外键会抛出异常，然后你将陷入异常并向用户发送消息。没人和我的意思是NOBODY代码。我们所有程序员都喜欢匆匆忙忙地将所有酷炫的东西直接放在用户界面中。但就像我说的，我使用开放式规则的封闭系统。另一方面，索引 - 非常重要。先处理它。外键 - 只是语法上的绒毛。