SQL Server数据库模式能否始终强制其应用程序'；是否仅通过使用外键和检查约束来实现业务逻辑？

谢谢你之前的回答，但是根据他们的反馈，我已经修改了这个问题

如果问题的答案是否定的，那么可以通过任何其他方式强制执行数据的完整性。我不认为使用存储过程是足够的，因为它们可能被规避。

---

是否需要触发器？

可以在数据库级别使用所有逻辑，但不能仅使用数据库模式。您可以通过存储过程和触发器在数据库级别实现所有逻辑，但这可以是：

难以实施

难以维护

缓慢，因为所有处理都将在服务器上运行，并且不会利用客户端机器的能力

---

我认为您最好通过存储过程实现业务逻辑，但同样，您可能会在服务器上施加很大的负载（取决于客户端、事务等的数量）。

否。有些业务逻辑涉及计算。DBMS当然可以进行计算，但这将是“通过使用内置函数”，而不是引用完整性。

在SQL术语中，引用完整性约束通常意味着外键

也许您指的是数据完整性约束？如果是这样，我们可能应该扩展您的定义，包括

createassertion

和

createdomain

。这将允许强制执行任意复杂性的约束。然而，“任何给定的业务逻辑”在实践中都是不合理的要求，在DBMS级别强制执行每个业务规则可能是不可取的

---

谢谢你的意见。然而，我特别关注外键和检查约束

我可以问一下为什么吗？从表面上看，这似乎是一种任意的分类

这将取决于您心目中的

检查

约束是否支持子查询。如果是，则这仍将允许任意复杂度的约束，但只会在正在更新的表上触发，即，如果

检查

约束定义涉及两个表，则第二个表上可能需要一个互补的

检查

约束

---

我说，我不知道支持SQL查询的工业产品SQL产品（Access数据库引擎，但我不认为它是工业实力）。但是，许多SQL产品都提供了一种变通方法，支持子查询（以及过程代码等）。也许你的定义应该允许跳跳虎。Date最近的一本书《数据库探索》中的脚注回答了这个问题：

“值得顺便注意的是，这一事实意味着所有可能的数据库约束都可以表示为IND”

IND是“包含依赖项”，它们基本上与SQL的外键相同，但忽略了SQL施加的限制

编辑

作为对“是否需要触发器”的回应：“数据库专业人士应用数学”有一个完整的专门章节，介绍如何编程触发器以强制执行任意业务规则。仅这一章就足以使这本书物有所值

---

顺便说一句，如果您使用安全系统阻止对表的所有“直接”访问，则存储过程是不可绕过的。当然，您必须依赖于安全规则的正确定义和管理…

否。有许多业务规则不能仅用检查约束和外键约束来表示。实际上，甚至SQL中的引用完整性约束支持也非常有限

例如，给定两个名为Employee和Department的表，我可以很容易地强制执行一个规则，即每个员工必须被分配到一个部门，但我也不能强制执行一个规则，即每个部门必须由至少一个员工引用。从技术上讲，我可以为此创建约束，但SQL不允许我更新表

---

ISO标准SQL确实有一个createassertion特性，该特性应该用于一般用途的约束实施，但大多数DBMS不支持它。即使创建断言功能可用，但由于SQL缺乏对多个赋值的基本支持，该功能也会受到影响——一次只能更新一个表。有效的业务规则实施需要一个允许多次分配的数据库模型。

不清楚。你的意思是“是否有任何业务逻辑可以由RI强制执行？”答案是肯定的，这样的业务逻辑是存在的。或者你的意思是“所有业务逻辑都可以由RI强制执行吗？”答案是否定的，这是一个无限的要求，可以包含任何内容。我的意思是所有业务逻辑都可以由RI强制执行吗？@onedaywhen-感谢您的编辑！那更好！非常感谢。这是否意味着需要使用触发器？不一定。这仅仅意味着外键和检查限制可以强制执行某些业务逻辑规则，但其他可能需要计算（如SUM、AVG）、比较（其中Title='Sr.Developer'）或数据库之外的代码。有趣的是，您可以指定这些限制是什么吗？在我看来，允许外键引用视图将使确保数据完整性变得更加容易。但是，我理解这可能会对数据库性能造成不可接受的限制。限制是引用表达式必须是表名（SQL），而不是任何任意表达式（relationland），引用表达式必须是表名（SQL），而不是（对于这种特殊情况）表示空关系（relationland）的关系文本，以及构成引用的列集，要求>=1（SQL），而不是可能也是空的（relationland）。因此，如果您以经典的、非常严格/严格的SQL意义解释术语“RI”，那么答案是i