database-design - 数据库设计 - 多个查找/枚举表还是一个大表？

Question

我有很多表，它们的大多数列值都使用 Lookup/Enum 引用。
例如:

人员表 - PersonID |种族代码 |头发颜色代码 |发型代码 | dentry 状况代码

位置表 - LocationID |尺寸代码 |外观颜色代码 |条件代码

Race、Size、Color、Condition 等只是对代码查找表的外键引用。此代码表有其他字段，但对我的问题并不重要。该数据库用于 SaaS 应用程序，这意味着每个客户都可以拥有自己的颜色、种族、条件等列表。有些代码是静态的，客户无法更改。

最好有 1 个代码表或 2 种类型的代码表(DynamicCodeTable 用于客户定义的代码表，StaticCodeTable 用于更改的代码表)还是我应该为每种代码类型(RaceCodeTable、HairColorTable、Condition 等)提供一个表？

我最担心的就是所有的sql join。我正在使用的 Person 表有 20 多个这样的代码属性。加入 20 个不同的表 VS 加入同一个表 20 次时，性能是否有差异？拥有多个表意味着每个表会更小，查找“应该”花费更少的时间。但是拥有一张 table 也可以很快。有什么建议？

Answer 1

在过去的 15 年中，在“一个真实的查找表”(缩写为 OTLT)主题下对这个主题进行了详细讨论。这种方法的优势突显到了数据库新手身上。缺点随着时间的推移而出现。请参阅以下链接了解 OTLT 缺点:

http://tonyandrews.blogspot.com/2004/10/otlt-and-eav-two-big-design-mistakes.html

http://web.archive.org/web/20100130062850/http://www.dbazine.com/ofinterest/oi-articles/celko22

或 search为 OTLT找到更多讨论。

如果您创建许多查找表，并为它们创建许多维护屏幕，您可以创建一个模拟 OTLT 的 View ，方法是创建一个巨大的 UNION，其中包含每个代码、每个描述以及存储代码-描述对的表的名称.
如果您知道自己在做什么，则可以使用半自动方法生成这样的联合。我想半自动方法将使您能够为数百个查找表构建单个维护屏幕，然后在该屏幕和表之间放置一些逻辑，以便在正确的表中插入新代码。

至于让用户引入新代码 TYPES，而不仅仅是新代码 VALUES，这就打开了一大堆蠕虫。请参阅上面讨论 EAV 的文章。这是非常诱人的，因为它允许用户设计自己的底层数据结构。如果你不考虑性能，这在一段时间内效果很好。您无需从用户或主题专家那里学习数据结构，即可获得一个完美通用的数据库。

当它遇到真正的悲伤时，是当您尝试将数据当作一个集成数据库来使用时，而不仅仅是对数据的杂乱无章的意见的大杂烩。在这一点上，当您的客户期望生成例行报告时，您就进入了一些严肃的数据考古学。祝你好运。

(编辑将“数据挖掘”更改为“数据考古”)