使用 SQL Server 检查约束或应用程序逻辑来保持用户 ID 的参照完整性？答案

【问题标题】：Use SQL Server check constraints or Application logic to keep Referential Integrity on User Id?使用 SQL Server 检查约束或应用程序逻辑来保持用户 ID 的参照完整性？
【发布时间】：2015-11-08 09:42:41
【问题描述】：

出于审核目的，我在数据库中的每个 Sql Server 表都有一个“LastUpdatedUserId”和“CreateduserId”列

这些列是 ApplicationUser 表的外键

严格来说，每个表的两列都应该有一个检查约束

然而，这使得数据图表不可读且无法布局

应用程序负责使用当前登录的“ApplicationUser”更新这些列

所以....

...我应该使用 SQL 服务器检查约束还是依赖应用程序来强制执行参照完整性

【问题讨论】：

是什么让数据图表不可读？外键？我不确定你在问什么。是否要删除外键？因为根据您当前对与用户表作为外键链接的所有审计表的设计，可确保引用完整性。
我有 85 个表，所有这些表都有（至少）2 列，它们是 ApplicationUser 表的外键。 table 之间还有许多其他关系。因此，仅来自 ApplicationUser 表的数据图就有超过 170 条关系线。您可以想象阅读图表有多困难......！

标签： sql-server referential-integrity

【解决方案1】：

我应该使用...

始终检查约束。没有任何外部应用程序可以比在 SQL Server 中内部管理 RI 更好地实施 RI。这就是我们使用 SQL Server 的原因。

数据图表不可读且无法布局

尝试更好的排版软件。在任何情况下都不应影响您的 RI 需求。

严格来说...

您已经回答了自己的问题...

跟进

如果您使用 LINQ 或某些 UI 强加的类型约束，则无关紧要。首先，您的数据必须是可靠的（满足引用完整性）。无论您是在 SQL 中还是在您的应用程序中执行此操作都无关紧要。只是在处理类型安全（由强类型模型强加）之前首先需要 RI。 Erik Meijer（LINQ 的设计者）曾经有视频解决了这个问题。

【讨论】：

那是“SQL 开发人员”或纯粹主义者的观点。该应用程序是强类型的并使用 LINQ to SQL，只能通过单一方法从 ApplicationUser 表中获取一个 ID 值。如果有人错误地添加代码以使用任意 ID 值，则查询“谁更新了此值”将给出错误的用户（测试将消除这一点）或者如果 ID 值不在 ApplicationUser 表中（异常处理将处理这个）
...不施加约束是以开发人员为中心的观点...我认为这两个阵营永远不会达成一致。有人可能会引入破坏完整性的错误。此外，约束和外键可以帮助提高性能。
但是 - 需要考虑可维护性的 SQF，例如可读性和可理解性。作为经常被要求“修复代码”的承包商，最大的问题是足够了解以找到问题所在，并在不引入新缺陷的情况下修复它。在这种情况下，SQL RI 会使这变得非常困难 - 数据图几乎无法破译。 .注释 User 类和方法使其非常清楚。此外，软件设计文档将记录 RI 决策及其原因
@AndrewBingham 正如您所说“...SQL RI 会让这变得非常困难...”是真的。但更真实的是，在 4 年的制作过程中破译一种计算机语言是非常容易和合乎逻辑的，而不是用任何月份语言的风格进行调试，或者依赖于文档实践或写作技巧。原程序员。 SQL 早于类和方法的 OO 编程范式，并将在每一种以咖啡口味命名的语言中存活下来。
我认为相反，SQL 数据库和 T-SQL 已有 4 年的历史，现在都过时、笨拙、难以使用（与 .Net 相比）并且 SQF 很差。另一方面，语言已经发展和改进，而且——同样重要的是——它们现在已集成到框架和环境（.Net 和 Visual Studio）中。有趣的是，微软在 SQL Server 和 T-SQL 上实现同样的目标是多么困难 - SQL 管理站正在逐渐被购买以适应现代语言环境，但仍然很差

【解决方案2】：

至于我发布的另一个问题 - 我通过使用 ORM 解决了这个问题 (DevExpress XPO)

这几乎将所有数据库抽象出来——因此在 OO 应用程序中（几乎）不需要考虑持久对象的数据存储

【讨论】：