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

我有许多表，它们的大多数列值都使用Lookup/Enum引用。 例如：
人名表-人名ID |种族代码|发型代码|发型代码|牙齿条件代码
位置表-位置ID |大小代码|外部颜色代码|条件代码
种族、大小、颜色、条件等只是代码查找表的外键引用。此代码表有其他字段，但对我的问题不重要。该数据库用于SaaS应用程序，这意味着每个客户端都可以有自己的颜色、种族、条件等列表。有些代码是静态的，客户端无法更改。

最好是有一个代码表或两种类型的代码表（对于客户定义的代码表是DynamicCodeTable，对于一次更改的代码表是StaticCodeTable），还是应该为每种代码类型（RaceCodeTable、HairColorTable、Condition等）有一个表？

---

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

我错误地认为，在重新设计相当宽的表时，所有这些查找表都是一个好主意。这么多的灵活性，等等，但它最终变得更难编码，不可能到处导航，这只是一个痛苦的屁股

那么我学到了什么

• 对于静态值，只需使用枚举-它更快更方便。必须根据有多少其他表引用同一变量来做出此决定
• 坚持使用较少的查找表，而不是创建尽可能多的查找表。连接要慢得多
• 要帮助自己导航，请设计数据库视图。这会让你的生活轻松很多
• 另外，如果您不希望您的客户端接触某些表（即静态表），或接触枚举列值，则可以使用MySQL（例如）细粒度权限来禁用对某些表中某些列的更改。很多人没有意识到这些权限有多灵活

---

在不了解更多应用程序或要求的情况下，我建议为每种代码类型提供一个表。在我看来，数据库设计将更加清晰和自我记录，为您拥有的每种代码类型提供外键
存在潜在的性能差异
只有两行的表在缓存中为这两小行占用了大量空间

---

如果在一个表中有很多查找值，则可以更有效地将这些值密集地打包到缓存中
在过去的十五年中，在“一个真正的查找表”（缩写为OTLT）的主题下，对这个主题进行了详细的讨论。对于数据库新手来说，这种方法的优点一跃而出。随着时间的推移，缺点逐渐显现出来。有关OTLT缺点，请参见以下链接：
或用于

OTLT

以查找更多讨论
如果为它们创建许多查找表和许多维护屏幕，则可以创建一个模拟OTLT的视图，方法是创建一个包含每个代码、每个描述以及存储代码描述对的表的名称的庞大联合。 如果您知道自己在做什么，那么可以使用半自动方法生成这样的联合。我可以想象，半自动方法将使您能够为数百个查找表构建一个维护屏幕，然后在该屏幕和将在正确表中插入新代码的表之间放置一些逻辑
至于让用户引入新的代码类型，而不仅仅是新的代码值，这就打开了一个很大的漏洞。请参阅上面讨论EAV的文章。这非常诱人，因为它允许用户设计自己的底层数据结构。如果不考虑性能，这在一段时间内效果相当不错。您可以获得一个完全通用的数据库，而不必向用户或主题专家学习数据结构
当你试图把数据当作一个完整的数据库来使用，而不仅仅是一堆杂乱无章的关于数据的观点时，它才是真正的悲哀。在这一点上，当您的客户期望常规报告生成时，您正在进行一些严肃的数据考古。祝你好运

---

（编辑后将“数据挖掘”改为“数据考古”）
每个查找表都会比这个大。每个客户都可以有自己的发型代码。因此，每个客户可以有自己的10种颜色、10种条件、10种尺寸。问题是我是将这30个代码放在一个表中，还是放在三个表中？这些数字只针对一个客户，理想情况下，我们会有多个客户。因此，一百个客户可以为每个属性拥有自己的一组10个代码。我完全不同意——如果一个表只有两列，比如id和value，那么在任何给定的8k页面上都可以容纳更多的行。我不明白你怎么会那样浪费记忆。我认为，有单独的、不同的查找表是一种更干净、更“可发现”的设计，特别是对于可能在不同版本之间更改的查找值，或者需要最终用户在任何给定时间更改的查找值。@marc_s:一个8k页面上可以“容纳”很多行。如果查找中只有两行，那么这两行在该页上，没有其他内容。我的抱怨是：如果你只使用枚举，那么它们只是你应用程序的一部分。这意味着1）当查找值中的某些内容发生更改时，您需要发布一个新版本；2）您无法在数据库上强制执行完整性（或者您必须“kl”