外键和检查约束的完整性

Jer*_*wer 11 database-design referential-integrity constraints

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

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

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

表:系统

ID Description
 1 Slave System 1
 2 Slave System 2
Run Code Online (Sandbox Code Playgroud)

表:行动

ID  Description
 1  Insert
 2  Update
 3  Delete
Run Code Online (Sandbox Code Playgroud)

表:Sync_action

ID  Action  System
 1     1       1
 2     2       1
Run Code Online (Sandbox Code Playgroud)

选项2)而不是外键使用sync_action.action列上的检查约束,因此只能Insert/Update/Delete插入操作.

表:Sync_action

ID  Action  System
1   Insert    1
2   Update    1
Run Code Online (Sandbox Code Playgroud)

我想知道在确定完整性约束,外键和检查约束之间确定哪种因素是更好的方法.有类似的线程,但我没有找到它们的确定性.这可能是因为它的解释,但任何想法将不胜感激.

干杯

ype*_*eᵀᴹ 8

评论员似乎非常同意:

FOREIGN KEY对(或多或少静态)引用表进行约束通常更好.原因:

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

  • 您可以附加额外的信息(更多列),如果需要,可以由应用程序读取.

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

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

  • 一个特定的DBMS尚未实现CHECK约束(羞耻),尽管它确实有FK.

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

表:系统

SystemID Description
 1        Slave System 1
 2        Slave System 2
Run Code Online (Sandbox Code Playgroud)

表:行动

ActionCode Description
 I          Insert
 U          Update
 D          Delete
Run Code Online (Sandbox Code Playgroud)

表:SyncAction

ID  ActionCode  SystemID
 1     I          1
 2     U          1
Run Code Online (Sandbox Code Playgroud)