数据库设计：被其他实体引用的“代码”表

Posted 2023-02-26

【中文标题】数据库设计：被其他实体引用的“代码”表

【英文标题】：database design: a 'code' table that get referenced by other entities

【发布时间】：2010-01-26 10:03:11

【问题描述】：

我正在构建一个数据库作为一个简单的练习，它可以托管在任何数据库服务器上，所以我尽量保持标准。基本上我想做的是一个被其他实体引用的“代码”表。我解释一下：

xcode
id code
r  role
p property

code
r admin
r staff
p title
....

那么我想有一些像这样的观点：

role (select * from code where xcode='r')
r admin
r staff

property (select * from code where xcode='p')
p title

那么，假设我们有一个实体

myentity
id - 1
role - admin (foreign key to role)
title - title (foreign key to property)

显然我无法为视图创建外键，但这是为了说明我的想法。我如何尽可能使用标准 sql 语法来反映这种行为，然后作为第二种选择，使用数据库附加功能，如 trigger ecc...？

因为如果我告诉 myentity 中的角色和标题是“代码”的外键，而不是视图，没有什么能阻止我在标题字段中插入角色。

【问题讨论】：

欢迎您！您需要将代码缩进 4 个空格，或使用编辑器中的 101010 按钮，以使其正确呈现。我已经为你解决了这个问题。

【参考方案1】：

我曾研究过对所有代码都有一个表的系统，而在其他系统中每个代码只有一个表。我绝对更喜欢后一种方法。

每个代码一个表的优点是：

外键。正如您已经发现的那样，不可能通过单个表的外键强制遵守允许的值。使用检查约束是一种替代方法，但维护成本较高。 性能。代码查找通常不是性能瓶颈，但如果优化器知道它正在从四行而不是四百行的表中检索记录，它无疑有助于优化器对执行路径做出明智的决定。 代码组。有时我们希望将代码组织成子部分，通常是为了更容易呈现复杂的值列表。如果我们每个代码都有一个表格，我们在结构方面会更加灵活。

此外，我注意到您希望能够“在任何数据库服务器上”进行部署。在这种情况下，避免触发。在大多数情况下，触发器通常是坏消息，但它们具有特定于产品的语法。

【参考方案2】：

在大多数情况下，您尝试做的是反模式和设计错误。只需创建不同的表而不是视图。

在极少数情况下，这种设计是有意义的。在这种类型中，包括主键/外键中的 xcode 字段。所以你的实体看起来像这样：

myentity
id - 1
role_xcode
role - admin (foreign key to role)
title_xcode
title - title (foreign key to property)

然后您可以创建检查约束来强制执行 role_xcode='r' 和 title_xcode='p'

（对不起，我不知道它们是否是标准的，它们确实存在于 oracle 中并且非常简单，以至于我希望它们也出现在其他 rdbms 上）