数据库设计 - 多查找/枚举表或一个大表？

我有很多表使用Lookup/Enum引用的大部分列值。例如：
Person Table - personID | RaceCode | HairColorCode | HairStyleCode | TeethConditionCode
Location Table - LocationID | SizeCode | ExteriorColorCode |条件代码
像种族，大小，颜色，条件等的东西只是对代码查找表的外键引用。这个代码表有其他领域，但对我的问题并不重要。该数据库用于SaaS应用程序，这意味着每个客户端都可以拥有自己的颜色，种族，条件等列表。有些代码是静态的，客户端无法更改。

有1个代码表或2种类型的代码表（DynamicCodeTable用于客户定义的和StaticCodeTable用于那些更改）还是应该为每个代码类型（RaceCodeTable，HairColorTable，Condition，等等）？

我最担心的是所有的sql连接。我正在使用的Person表有20多个这些代码属性。加入20个不同的表时，性能是否有差异？VS连接到同一个表20次？拥有多个表格意味着每个表格会更小，查找'应该'需要更少的时间。但有一张桌子也可以很快。有什么建议么？数据库设计 - 多查找/枚举表或一个大表？

来源

2009-05-18 Vyrotek

不知道更多关于应用程序或需求我建议每个代码类型都有一个表。国际海事组织的数据库设计将更加清晰，并自我记录每种类型的代码都有外键。

来源

2009-05-18 02:30:09 Jeff

我犯了一个错误，认为在重新设计我们非常宽的表格时，所有这些查找表都是一个好主意。如此多的灵活性等，但最终难以编码，无法导航，这只是一个痛苦的屁股。

那么我学到了什么？

对于静态值，只需使用枚举 - 它会更快，更方便。这个决定必须取决于有多少其他表可能引用同一个变量。
坚持使用更少的查找表，而不是创建尽可能多的，你可以想到的。 JOINs要慢得多。
帮助你自己导航，设计数据库视图。它会让你的生活变得更轻松。
作为一种奖励，如果您不希望客户触及某些表格（即静态列表）或触摸枚举列值，则可以使用MySQL（例如）精细的权限来禁用对某些列的更改在某些表格中。很多人没有意识到这些权限可以得到多么灵活。

来源

2009-05-18 02:29:07

我抱怨这一点：如果你只使用枚举，那么他们只是你的应用程序的一部分。这意味着1）每次查找值中的某些内容发生更改时，您需要发布新版本; 2）您无法在数据库中强制执行完整性（或者您必须用杂乱的CHECK约束来“克隆”自己的方式）。因此，我会争论使用查找表查找所有查找值，而不仅仅是真/假字段。 – 2009-05-18 04:55:42

或者定义你的查询表，并具有正常的参照完整性，但是从数据库生成你的枚举定义。这样你对枚举进行编程，并且它们与数据库匹配。 – GalacticCowboy 2009-05-18 12:09:22

存在潜在的性能差异。

只有2行的表格为这两个小行占用了缓存中的大量空间。

如果在单个表中有很多查找值，则可以将这些值更加密集地打包到缓存中。

来源

2009-05-18 02:35:32

在主题为“One True Lookup Table”（缩写为OTLT）的主题下，本主题已经过去十五年的详细讨论。这种方法的优点跳到了数据库新手。随着时间的推移会出现弊端。看到这些链接，OTLT缺点：

为 OTLT

或者search找到更多的讨论。

如果您为它们创建了许多查找表以及许多维护屏幕，您可以创建一个视图来模拟OTLT，方法是创建一个巨大的UNION，其中包含每个代码，每个描述以及表的名称，描述对被存储。如果您知道自己在做什么，可以使用半自动方法生成这样的联合。我会想象半自动方法可以让你为数百个查找表建立一个维护屏幕，然后在该屏幕和表格之间插入一些逻辑，以便在正确的表格中插入一个新代码。

至于让用户介绍新代码TYPES，而不仅仅是新代码VALUES，那就打开了一大堆蠕虫。请参阅上面讨论EAV的文章。这非常诱人，因为它允许用户设计自己的基础数据结构。如果你忽略了表现，这一段时间运作良好。您无需从用户或主题专家那里学习数据结构，即可获得完美的通用数据库。

当它发生真正的悲痛时，当你试图将数据当作一个综合数据库使用时，而不仅仅是对数据的不连贯的意见大杂烩。此时，当您的客户期望生成日常报告时，您将进入一些严肃的数据考古。祝你好运。

（Editted为“数据挖掘”更改为“数据考古”）

来源

2009-05-18 12:06:52

数据库设计 - 多查找/枚举表或一个大表？

回答

相关问题