用于数据完整性的触发器/存储过程答案

【问题标题】：Triggers / Stored Procs for Data Integrity用于数据完整性的触发器/存储过程
【发布时间】：2015-02-24 15:05:15
【问题描述】：

我有一个名为 Documents 的表，它存储有关文档的文件名、注释等。相关字段是：

Table_Unique_ID 与其他表中使用的任何其他 ID 相关，并且我们通过相关的Document_Type_ID 知道哪个表。

例如

Document_Type_ID = 1 与Projects 表相关，因此Table_Unique_ID 为1357 和Document_Type_ID 为1 的文档记录表示它与Project_ID = 1357 相关。
Document_Type_ID = 2 与 Sites 表相关，因此具有 1357 的 Table_Unique_ID 和 2 的 Document_Type_ID 的文档记录意味着 1357 的 Site_ID

等等。

这为我们为任何表中的各种记录保存的文档类型提供了极大的灵活性，Projects、Sites、Contacts 等，而不是创建单独的表（Project_Documents、Site_Documents 等）。）。

但是有人指出，使用传统的简单 PK/FK 关系很难（或不可能）强加数据完整性，因为 1357 可能与 Projects 或 Sites 相关。

目前数据完整性由用户界面检查处理。

问题是，在插入Document 记录或删除“其他”记录（Projects、Contacts 等）时，触发器或存储过程是否有帮助？

如果是这样，我将非常感谢您指出正确的方向。

【问题讨论】：

【解决方案1】：

您的主要目标是什么？数据完整性，还是灵活性和简洁的设计？这些是相互冲突的利益。如果您绝对必须在没有触发器的情况下强制执行完整性，那么您将不得不有一个更丑陋的设计。在数据库设计中总是必须做出妥协。你会让数据完整性精英们喋喋不休地抱怨这种设计有多糟糕，但归根结底，更规范化是否值得？

【讨论】：

在大多数严肃的业务应用程序中，数据完整性比“好的”设计重要得多……毕竟，数据是解决方案的基础。如果你有一个不错的设计，但你的数据质量很糟糕——你很快就会倒闭。不要为了诸如“新潮”设计之类的东西而牺牲所有重要的数据完整性 - 这些东西每月都会来来去去 - 您的数据将会存在（并且对您的业务很重要）几十年。最好保持良好状态！