0

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

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

4

5 回答 5

3

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

于 2011-11-22T13:09:43.410 回答
2

Date 的最新著作“数据库探索”中的一个脚注回答了这个问题：

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

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

编辑

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

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

于 2011-11-22T16:12:14.687 回答
2

不，有很多业务规则不能单独用 CHECK 约束和 FOREIGN KEY 约束来表示。在实践中，甚至 SQL 中的参照完整性约束支持也极为有限。

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

ISO 标准 SQL 确实具有 CREATE ASSERTION 功能，该功能应该用于执行通用约束，但大多数 DBMS 不支持它。即使它可用，CREATE ASSERTION 功能也会因 SQL 缺乏对多重赋值的基本支持而受到削弱——一次只能更新一个表。有效的业务规则实施需要一个允许多重分配的数据库模型。

于 2011-11-23T06:41:50.457 回答
1

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

  1. 难以实施
  2. 难以维护
  3. 速度很慢，因为所有处理都将在服务器上运行，并且不会利用客户端计算机的电源。

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

于 2011-11-22T13:09:00.383 回答
1

在 SQL 术语中，参照完整性约束通常意味着外键。

也许您的意思是数据完整性约束？如果是这样，我们可能应该将您的定义扩展为包括CREATE ASSERTION，也许CREATE DOMAIN. 这将允许强制执行任意复杂性的约束。但是，“任何给定的业务逻辑”在实践中是不合理的要求，在 DBMS 级别强制执行每个业务规则可能是不可取的。

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

我可以问为什么吗？从表面上看，它似乎是任意的任意分类。

这取决于CHECK您考虑的约束是否支持子查询。如果是，那么这仍将允许任意复杂性的约束，但只会在正在更新的表上触发，即如果CHECK约束定义涉及两个表，则CHECK可能需要对第二个表进行补充约束。

也就是说，我不知道支持子查询的工业级 SQL 产品（Access Database Engine 支持，但我不认为它是工业级的）。但是，许多 SQL 产品提供了支持子查询（和过程代码以及更多）的解决方法。也许您的定义应该允许跳跳虎。

于 2011-11-22T14:45:13.103 回答