-1

我想知道您对在 MS SQL DB 中维护关系约束有何想法。

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

旧数据库中的应用程序数据库很大，一些表的用途将更改为开始包含二进制数据、文件等形式。我热衷于将这些数据拆分为单独的数据库以简化管理磁盘空间非常宝贵的客户站点。

保留表之间的关系约束有什么价值吗？

假设：

  • 代码经过测试
  • 在关系很重要的情况下，执行在事务下执行
  • 只能通过 API 访问数据库，不支持第三方的其他访问。

保持约束的原因：

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

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

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

3 回答 3

2

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

另请参阅此问题：数据库设计中是否真的需要外键？

于 2009-04-29T10:27:26.457 回答
1

是的，除非您有特定的理由不这样做，否则您应该对表进行外键约束。即使您的应用程序经过测试，它也可能不是唯一写入数据库的内容。FK 对来自所有来源的数据强制执行参照完整性。

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

如果您可以将特定的、与性能相关的问题追溯到外键，则可能需要删除该键。这只可能发生在一个或两个特定的大容量表上的少量键上。它也只有在交易量非常大的系统上才有可能是必需的。根本没有理由在数据库上没有外键。

于 2009-04-29T11:04:57.643 回答
1

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

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

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

于 2009-04-29T10:53:03.400 回答