database-design - 外键与完整性检查约束

Question

关闭。这个问题是opinion-based .它目前不接受答案。












想改善这个问题吗？更新问题，以便可以通过 editing this post 用事实和引文回答问题.

3个月前关闭。




Improve this question




我正在构建一个系统，它是一个中央存储库，用于存储来自许多其他系统的数据。当其他系统数据更新时，需要同步过程来更新中央存储库。将有一个 sync_action 表来标识中央存储库需要与哪个系统同步以及所需的同步类型。有一组不太可能改变的已定义操作。下面是一个精简的系统。

在我看来，我可以通过两种方式来解决这个问题:

选项 1 ) 有一个 Action具有 3 个可用操作的表。有一个 sync_action使用外键引用所需操作的表。

表:系统

ID Description
 1 Slave System 1
 2 Slave System 2

表: 行动

ID  Description
 1  Insert
 2  Update
 3  Delete

表: 同步 Action

ID  Action  System
 1     1       1
 2     2       1

选项 2 ) 在 sync_action.action 上使用检查约束代替外键列因此只有操作 Insert/Update/Delete可以插入。

表: 同步 Action

ID  Action  System
1   Insert    1
2   Update    1

我想知道在完整性约束、外键与检查约束之间做出决定时，哪些因素会影响确定哪种方法更好。有类似的线程，但我没有发现它们足够明确。这可能是因为它取决于解释，但任何想法都将不胜感激。

干杯

Answer 1

评论家们似乎一致同意:

通常最好有一个 FOREIGN KEY对(或多或少静态)引用表的约束。原因:

该约束很容易“扩展”。要添加或删除选项，您只需在引用表中添加或删除一行。您不必删除约束并重新创建它。更重要的是，如果您在其他表的类似列中也有相同的约束。

您可以附加额外的信息(更多列)，如果需要，应用程序可以读取这些信息。

ORM 可以更好地处理(阅读:注意)这些约束。他们只需要读取表格，而不是元数据。

如果您想更改操作代码，级联效果将处理其他(可能很多)表中的更改。无需编写 UPDATE 查询。

一种特定的 DBMS 尚未实现 CHECK约束(耻辱)，虽然它确实有 FK 的。

正如@pst 提到的(我非常喜欢这种方法)，您可以使用合理的代码而不是代理整数 ID。所以，你的表可能是:

表: 系统

SystemID Description
 1        Slave System 1
 2        Slave System 2

表: 行动

ActionCode Description
 I          Insert
 U          Update
 D          Delete

表: 同步操作

ID  ActionCode  SystemID
 1     I          1
 2     U          1