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

Question

冒着被称为傻瓜的风险，我想知道你在MS SQL DB中维护关系约束的想法。

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

旧数据库中的应用程序数据库很大，一些表的目的将改为开始包含文件等形式的二进制数据。我很想将这些数据拆分成单独的数据库以方便在磁盘空间非常宝贵的客户端站点进行管理。

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

假设：

• 代码已经过测试
• 在关系很重要的情况下，执行是在交易
下执行的
• 仅通过API访问数据库，不支持第三方进行其他访问。

保持约束的原因：

• 强制执行数据结构
• 加入更快？
• 查询计划协助？

删除新.NET版本中的约束的原因：

• 可以假设API / BIZ逻辑将管理诸如父/子之类的关系。
• 减少将数据库部分分成其他目录的机会（系统使用插件架构构建，大多数表可以独立运行）
• 我是否认为SQL必须在INSERT上对约束进行额外的检查，这在DB上方的API管理时可能是不必要的？

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

非常感谢，

森

Answer 1

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

另请参阅此问题：Are foreign keys really necessary in a database design?

Answer 2

我不支持约束“自动编入索引”的断言。只有唯一键和主键。外键没有，虽然在大多数情况下我会建议在匹配FK列的“child”上有一个索引。 不过我还是会推荐FKeys

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

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

Answer 3

是的，你应该对表有外键约束，除非你有特殊的理由不这样做。即使您的应用程序已经过测试，也可能不是唯一一个写入数据库的东西。 FK对所有来源的数据实施参照完整性。

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

如果您可以跟踪与外键有关的特定性能问题，则可能需要删除该密钥。这只能在一个或两个特定的高容量表上的少量键上发生。在交易量非常高的系统上，它也可能是必要的。根本没有借口在数据库上没有外键。