Sql 数据库表设计：如何使用多个表来分隔相关数据，以便查询结果集更简单或需要更少的代码？

我有三个表格，如下面的屏幕截图所示：

主要设计目标是将

许可证需求

表中的值：

税务

、

保险

和

福利

列与其

许可证需求描述

表中的描述分开

下面的查询返回

LICENSE\u REQ\u DESC

表中描述旁边的

TAX

、

INSURANCE

和

BENEFIT

列

查询：

表格：

业务

-

主密钥许可证\u ID

LICENSE\u REQ

-

Foreign Key LICENSE\u ID

LICENSE\u REQ\u DESC

-

Primary Key SEQ\u NBR

下面是

结果集

屏幕截图：

是否有一种更有效的方法将数据与元数据（描述）分离，以便高效地查询所需的

resultset

？

我喜欢你的方法

一些开发人员可能会创建一个存储函数，如

get\u desc（req\u code）

，并将SQL编写为：

SELECT A.LICENSE_ID, 
       B.TAX, 
       get_desc(B.TAX) TAX_DESC, 
       B.INSURANCE, 
       get_desc(B.INSURANCE) INSURANCE_DESC, 
       B.BENEFIT, 
       get_desc(B.BENEFIT) BENEFIT_DESC
FROM BUSINESS A INNER JOIN LICENSE_REQ B ON A.LICENSE_ID = B.LICENSE_ID

但我更喜欢你的方式。尽可能将其全部保存在纯SQL中

我喜欢你的方式

一些开发人员可能会创建一个存储函数，如

get\u desc（req\u code）

，并将SQL编写为：

SELECT A.LICENSE_ID, 
       B.TAX, 
       get_desc(B.TAX) TAX_DESC, 
       B.INSURANCE, 
       get_desc(B.INSURANCE) INSURANCE_DESC, 
       B.BENEFIT, 
       get_desc(B.BENEFIT) BENEFIT_DESC
FROM BUSINESS A INNER JOIN LICENSE_REQ B ON A.LICENSE_ID = B.LICENSE_ID

---

但我更喜欢你的方式。尽可能将其全部保存在纯SQL中

单一查找表方法有赞成和反对两种

主要优点是所有的翻译都在一个地方，你不需要到处搜索就能找到每个翻译

缺点是，由于连接中通常包含一个鉴别器列，因此最终会得到更大的查找表和更复杂的连接要求，并且每个查找只能使用完全相同的属性

现在，您的方案不包括一个鉴别器列，用于根据

LICENSE\u REQ\u DESC

的内容确定描述所使用的代码值源。如果由于某种原因，

税务

、

保险

和

福利

代码列之间存在

REQ\u code

值冲突，则这可能是一个问题

LICENSE\u REQ\u DESC

表的改进版本是：

ALTER TABLE LICENSE_REQ_DESC ADD (REQ_CODE_SOURCE VARCHAR2(15) );

用适当的值填充新列，例如“税收”、“保险”和“福利”，然后：

ALTER TABLE CODE_LOOKUP MODIFY (REQ_CODE_SOURCE NOT NULL);
ALTER TABLE CODE_LOOKUP ADD CONSTRAINT CODE_LOOKUP_UK UNIQUE 
(
  REQ_CODE_SOURCE 
, REQ_CODE 
)
ENABLE;

最后将查询更改为使用以下联接：

LEFT OUTER JOIN LICENSE_REQ_DESC T ON T.REQ_CODE_SOURCE = 'TAX' AND B.TAX = T.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC I ON T.REQ_CODE_SOURCE = 'INSURANCE' AND B.INSURANCE = I.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC J ON T.REQ_CODE_SOURCE = 'BENEFIT' AND B.BENEFIT = J.REQ_CODE

---

单个查找表方法有赞成和反对的两种

主要优点是所有的翻译都在一个地方，你不需要到处搜索就能找到每个翻译

缺点是，由于连接中通常包含一个鉴别器列，因此最终会得到更大的查找表和更复杂的连接要求，并且每个查找只能使用完全相同的属性

现在，您的方案不包括一个鉴别器列，用于根据

LICENSE\u REQ\u DESC

的内容确定描述所使用的代码值源。如果由于某种原因，

税务

、

保险

和

福利

代码列之间存在

REQ\u code

值冲突，则这可能是一个问题

LICENSE\u REQ\u DESC

表的改进版本是：

ALTER TABLE LICENSE_REQ_DESC ADD (REQ_CODE_SOURCE VARCHAR2(15) );

用适当的值填充新列，例如“税收”、“保险”和“福利”，然后：

ALTER TABLE CODE_LOOKUP MODIFY (REQ_CODE_SOURCE NOT NULL);
ALTER TABLE CODE_LOOKUP ADD CONSTRAINT CODE_LOOKUP_UK UNIQUE 
(
  REQ_CODE_SOURCE 
, REQ_CODE 
)
ENABLE;

最后将查询更改为使用以下联接：

LEFT OUTER JOIN LICENSE_REQ_DESC T ON T.REQ_CODE_SOURCE = 'TAX' AND B.TAX = T.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC I ON T.REQ_CODE_SOURCE = 'INSURANCE' AND B.INSURANCE = I.REQ_CODE
LEFT OUTER JOIN LICENSE_REQ_DESC J ON T.REQ_CODE_SOURCE = 'BENEFIT' AND B.BENEFIT = J.REQ_CODE

---

这里有一些有趣的阅读（否定）：

（虽然不是每个人都同意乔·塞尔科的观点，但他总是深入研究）

要考虑的是你的外键。可以对此表强制外键，但不能强制税务交易记录只能使用税务说明记录

外键强制执行逻辑，可以帮助生成有效的查询计划。当您创建的外键不能完全说明全部情况时，它似乎表明存在设计问题

---

展望未来：这个查找表最终会被扩展以存储许多其他类型的描述吗？描述类型的分布会以某种方式严重倾斜吗？当您的表的用途（以及内容和基数）随着时间的推移而改变时，当统计数据过时时，可能会导致“随机性能问题”。

这里有一些有趣的阅读（否定）：

（虽然不是每个人都同意乔·塞尔科的观点，但他总是深入研究）

要考虑的是你的外键。可以对此表强制外键，但不能强制税务交易记录只能使用税务说明记录

外键强制执行逻辑，可以帮助生成有效的查询计划。当您创建的外键不能完全说明全部情况时，它似乎表明存在设计问题

---

展望未来：这个查找表最终会被扩展以存储许多其他类型的描述吗？描述类型的分布会以某种方式严重倾斜吗？当您的表的用途（以及内容和基数）随着时间的推移而变化时，当统计数据过时时，可能会导致“随机性能问题”。

不要在

选择中包含描述列。您不是在设计一个表..只是从多个表中查询。加上uno，可以获得组织良好且具有视觉吸引力的问题。祝你好运，谢谢！我需要非常清楚，以便读者能够理解我试图实现的目标。上面的解决方案是有效的，但这是更有效的方法吗？模式看起来不错。我不明白你的问题是什么。当你要求效率时，你的目标是什么