gpt4 book ai didi

数据库设计: a 'code' table that get referenced by other entities

转载 作者:搜寻专家 更新时间:2023-10-30 23:24:07 25 4
gpt4 key购买 nike

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

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)

显然我不能为 View 创建外键,但这是为了说明我的想法。我如何尽可能使用标准 sql 语法来反射(reflect)此类行为,然后作为第二个选项,数据库附加功能(如触发器 ecc...)?

因为如果我告诉我实体中的角色和头衔是“代码”的外键,而不是 View ,那么没有什么能阻止我在头衔字段中插入角色。

最佳答案

我曾经在一个系统上工作过,所有代码都用一个表,而其他系统每个代码一个表。我绝对更喜欢后一种方法。

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

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

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

关于数据库设计: a 'code' table that get referenced by other entities,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/2138658/

25 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com