没有关系/关系的数据库设计,我应该使用外键吗?

时间:2017-01-28 05:16:46

标签: sql-server database database-design foreign-keys

我遇到了决定性的局面。它与RDBMS尤其是SQL Server有关。

根据我的想法,任何数据库都有多个表,这些表在查询时通过密钥或通过连接直接互连。现在按照我的理解,我会想到两个选项来设计数据库。

1 - 没有关系(没有外国钥匙)

如果我没有在表之间提供任何外键关系,我可能没有参照完整性,但我可以删除带有PK的父记录,但仍然保持子记录不变。如果我在父母中重新创建PK记录,再次在加入时它开始引用它的孩子。这是一个好处。但我必须更新所有表记录如果我更新父PK记录。这就是缺点。

2 - 与关系(与外国钥匙)

如果我在表之间建立了FK,我不需要为这些记录的更新和删除做额外的编码。但是当我想删除PK或父记录时出现问题。因此,我需要在每个表中提供一些IsActive列,然后我必须在我使用的每个查询中查找IsActive列。那非常讨厌和冗长。所以它也不完美。

现在,您可以建议我出于这种困境,我的数据库设计模式应该是什么?

2 个答案:

答案 0 :(得分:4)

数据完整性是使用关系数据库的主要好处,因此我建议保持参照完整性约束。在没有外键的情况下处理数据库之后,最好避免识别和修复孤立数据。

答案 1 :(得分:1)

首先要做的事情。即使模式中未声明外键约束,外键也是外键。具有未被声明的外键的结果是DBMS不提供防止插入无效键值或孤立先前有效值的保护。责任落在应用程序程序员或交互式用户身上。

其次,即使已声明外键,在调用时也会在查询中使用连接。学习如何以及何时使用连接是学习如何从关系数据库中检索数据的基础。

第三,术语"关系"虽然外键是数据关系模型中不可或缺的一部分,但它比外键更多。如果您正在构建SQL数据库,那么设计基于数据的关系模型的可能性很大,即使您只是初学者也是如此。它是否是一个良好的关系模型是另一回事。

接下来,可以声明外键而不必在删除和更新时使用CASCADE选项。所以你可能仍然需要做一些额外的编程来处理这些情况。

最后,如果你真的在询问,在不删除其中一个孩子的情况下要删除父记录的位置,作为程序员或用户,你有责任打破这种关系(可能是在删除父记录之前将FK值设置为NULL。

所以长期和短期是,是的,你必须做一些小的数据管理,并且正确地做,即使你让DBMS为你做了所有繁重的工作。这是一个不完美的世界。