SQL-间接外键

Question

我对数据库设计有一些疑问。

有这个名字吗？

这是好习惯吗？

有性能方面的考虑吗？

我有一个用于存储关系的通用表结构。

最近，我重构了一些东西来使用这种通用结构，而不是直接使用Fk列，但是现在我不确定这是否真的是最好的主意。

原始架构：

 + ------------------ + + --------------------- + + ------ ---------------- +

 | 书本 | 注意事项 | MetaParent |

 | ------------------ | | --------------------- | | ---------------------- |

 | ID | | ID | | ID |

 | NoteId | | MetaParentId :(空）| | MetaTableId |

 | + ------- + + ---- + KeyValue |

 | | | | | |

 | | | | | |

 | | | | | |

 | | | | | |

 | | | | | |

 + ------------------ + + --------------------- + + ------ ---------------- +

新架构

 + ------------------ + + --------------------- + + ------ ---------------- +

 | 书本 | 注意事项 | MetaParent |

 | ------------------ | | --------------------- | | ---------------------- |

 | ID | | ID | | ID |

 | | | MetaParentId :(空）| | MetaTableId |

 | + + + ---- + KeyValue |

 | | | | | |

 | | | | | |

 | | | | | |

 | | | | | |

 | | | | | |

 + ------------------ + + --------------------- + + ------ ---------------- +

因此，基本上，与在Book和Note之间没有直接的Fk关系相比，我们通过使用MetaTableId / KeyValue列的MetaParent表具有间接关系。

当前，MetaParent表具有约50万条记录，并且一切运行正常。但是我们每天晚上都会重建索引。

我担心的是，现在Book和Note之间的关系并不明显。您必须知道一个存在并使用MetaParent表。

在性能方面，我不确定在什么时候遇到针对MetaTableId / KeyValue的连接运行太慢的问题。似乎您添加到该表中的越多，查询速度就越慢。

Answer 1

您应该始终通过使用“常规” FOREIGN KEY来强制实现引用完整性。简而言之，FOREIGN KEY具有以下优点：它们已经在DBMS中实现。它们是声明性的，自我记录的和“显而易见的”。它们不能被绕过（除非被明确禁用或删除）。他们是正确的。他们很快。它们支持级联引用动作（例如ON DELETE CASCADE）。DBMS知道数据是相关的，因此在某些情况下可以找到更好的查询计划。如果使用的是ORM工具，则它可以自动在对象之间生成引用。以下是在应用程序代码中强制执行引用完整性的相应缺点：您正在复制已经完成的工作。它势在必行，可能会“深埋”在您的应用程序源代码中，并且很难维护。具有错误的单个客户端应用程序可能会破坏参照完整性（并破坏数据）。您可能会在应用程序代码中错误地实现它们。从一开始看起来很简单，但是在并发环境中，很容易引入竞争条件。即使正确实现了它们，您也可能会使用某种形式的锁定来避免争用情况，这比DBMS中内置的经过特别优化的FK可能更慢/可扩展性更小。您必须自己实现级联。DBMS不知道数据是否相关，这可能会产生次优的查询计划。您可能需要在所选的ORM工具中进行更多的手动工作。有这个名字吗？从来没听说过。我听说使用了“通用FK”一词，但这可能不是通用的。这是好习惯吗？否（请参见上文）。有性能方面的考虑吗？是的（见上文）。