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)
我想知道在确定完整性约束,外键和检查约束之间确定哪种因素是更好的方法.有类似的线程,但我没有找到它们的确定性.这可能是因为它的解释,但任何想法将不胜感激.
干杯
评论员似乎非常同意:
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)