迁移数据库：保持关系约束？

Question

冒着被称为傻瓜的风险，我想知道您对维护 MS SQL 数据库中的关系约束有何想法。

我正在将系统从 ASP 迁移到 .NET 环境。这带来了业务对象和其他分层编码技术，这些技术可以从用户/API 中抽象数据库。新应用程序在实体框架 DAL 之上有一个明确的 API。

旧数据库中的应用程序数据库很大，某些表的用途将发生变化，开始包含文件形式的二进制数据等。我热衷于将它们分成单独的数据库，以简化磁盘空间非常宝贵的客户端站点的管理。

保留表之间的关系约束有任何价值吗？

假设：

• 代码已测试
• 当关系很重要时，执行是在事务下执行的
• 仅通过 API 访问数据库，不支持第三方的其他访问。

保留约束的原因：

• 强制执行数据结构
• JOIN 更快？
• 查询计划帮助？

在新的 .NET 版本中删除限制的原因：

• 人们可以假设 API/BIZ 逻辑将管理诸如父/子之类的关系。
• 减少将数据库的各个部分划分到其他目录中的机会（系统是使用插件架构构建的，大多数表可以独立运行）
• 我是否正确地相信 SQL 必须在 INSERT 期间对约束进行额外的检查，当数据库之上的 API 管理此操作时，这可能是不必要的？

无论如何，我都会向社区提出我的问题，以防我错过了一些愚蠢的事情，或者这只是一场等待发生的噩梦......

非常感谢，

内森

Answer 1

我不支持约束“自动索引”的说法。只有唯一键和主键可以。外键不需要，尽管在大多数情况下我建议在与 FK 列匹配的“子”上建立索引。尽管如此，我仍然会推荐 FKeys，因为它们

1. 将强制您的数据完整性（我已经多次被 BL 有错误并且未能完成这项工作所困扰）。
2. 为优化器提供有关数据模式的更多信息，这反过来可能会导致更好更快的执行计划。

但最重要的是，您是否考虑过将数据保存在单个数据库中，但将其分隔在多个文件组中？您可以实现更灵活的磁盘空间管理目标，而无需跨越多个数据库的外键的麻烦

Answer 2

是的，我建议保留关系约束。当然，您必须在 BLL 中处理它们，但约束也会提高性能，因为查询规划器使用它们来更有效地处理查询。

另请参阅这个问题： 数据库设计中外键真的有必要吗？

Answer 3

是的，您应该在表上设置外键约束，除非您有特定原因不这样做。即使您的应用程序经过测试，它也可能不是唯一写入数据库的内容。FK 对所有来源的数据强制执行引用完整性。

外键还充当数据库中关系的一种非正式文档工具。如果数据库中存在 FK，我可以使用 Visio（或支持逆向工程的任何其他工具）对架构进行逆向工程并查看关系。以性能的名义在数据库中删除外键是 ISV 用来混淆其数据库架构并带来更多支持收入的常用技术。

如果您可以跟踪与外键相关的特定性能问题，则可能需要删除该键。这种情况只可能发生在一个或两个特定的大容量表上的少量键上。而且只有在交易量非常高的系统上才可能需要它。数据库上没有外键是没有任何借口的。