在数据库中合并小型静态表是一种好习惯吗？答案

【问题标题】：Is it good practice to consolidate small static tables in a database?在数据库中合并小型静态表是一种好习惯吗？
【发布时间】：2011-05-19 01:33:15
【问题描述】：

我正在开发一个数据库来存储测试数据。每条数据有 11 个元数据标签。目前，我对每个元数据选项都有一个单独的表。我在这里看到了一些关于许多小表的最佳实践的问题，但我想我会为我自己的项目提出这个问题，因为我没有从其他问题中得到明确的答案。

这是我的表格列表，每个表格中都有字段：

Source Type - id, name, description
For Flight - id, name, description
Site - id, name, abrv, description
Stand - id, site (FK site table), name, abrv, descrition
Sensor Type - id, name, channels, descrition
Vehicle - id, name, abrv, descrition
Zone - id, vehicle (FK vehicle table), name, abrv, description
Event Type - id, name, description
Event - id, event type (FK to event type Table), name, descrition
Analysis - id, name, descrition
Bandwidth - id, name, descrition

您可以看到每个表格中的字段或多或少相同。三个表引用了另一个表。

最好只有一个名为 Meta 的大表，其中包含以下字段：

Meta: id, metavalue, name, abrv, FK, value, descrition

其中元值 = 上述表名之一
并且 FK = 对 Meta 表中另一行的引用而不是外键？

我是数据库新手，多张表似乎最直观，但一张表使编程更容易。

所以问题是：

减少表的数量并将所有静态值放在一个表中是否是一种好习惯。
有一个自引用表是不是很糟糕。

仅供参考，我正在使用 django 和 mysql 在具有 NTFS 格式的 Windows 服务器上制作这个 Web 数据库。

提示和最佳做法表示赞赏。

谢谢。

【问题讨论】：

Database Design - Multiple Lookup/Enum Tables or One Large Table? 的可能重复项

标签： mysql database django

【解决方案1】：

“只有一张大桌子会更好吗？” - 强调和明确地说，不！

这种反模式有时被称为“一张桌子来统治他们”！

Ten Common Database Design Mistakes：一张表保存所有域值。

在查询中使用数据要容易得多

可以非常自然地使用外键约束来验证数据，对对方来说不可行的事情解决方案，除非您实施范围每张桌子的钥匙——一个可怕的维护混乱。

如果事实证明您需要保留有关 ShipViaCarrier 不仅仅是代码， 'UPS'，以及描述，'United Parcel 服务”，那么就这么简单添加一两列。你甚至可以将表格扩展为完整的代表企业的是物品的载体。

所有较小的域表都将适合单个磁盘页面。这确保了单次读取（并且可能缓存中的单个页面）。如果对方情况下，你可能有你的域表分布在许多页面上，除非你引用表名上的集群，这可能会导致它更多使用非聚集索引的成本很高，如果你有很多价值观。

您仍然可以为所有行使用一个编辑器，因为大多数域表都会可能有相同的基础结构/用法。虽然你会失去查询所有域的能力一个查询中的值很容易，为什么会你想要？（联合查询可以轻松创建表格如果需要，但这似乎是不太可能需要。）

【讨论】：

已明确回答。你能解释一下为什么将一堆小表聚集在一起不是一个好主意吗？是不是因为将来我可能想扩展，这是最通用的解决方案？
请看链接的文章，路易斯戴维森解释得比我好。
感谢这是一篇内容丰富且内容广泛的文章。我将尝试将“代理键”合并到我的表中，以确保有一个人眼可以理解的元素，并维护我最初构想的规范化元表。
似乎有更多的人要做 cmets，我不想结束讨论。不确定接受答案是否确实如此，但我认为为了安全起见我会犯错。
@sequoia：好的。谢谢，我只是好奇。

【解决方案2】：

其中大多数看起来除了将代码扩展为描述之外不会做任何事情。你甚至需要桌子吗？只需定义一堆常量或代码，然后对代码进行详细描述的字典。

引用表中的字段只存储代码。例如：“SRC_FOO”、“EVT_BANG”等

【讨论】：

好吧，我选择了表格，因为并非所有的元值都已定义。在未来的测试中，我们可能会使用新值，我认为将新值添加到表中是最简单的。我们将有新的分析技术、新的带宽选择、新区域等。因此，当输入未来的数据时，新值将被添加到相应的表中，该值当前不存在。 - 但基本上你是对的，表存储短静态值，例如 source_foo 或 event_bang。我将在哪里定义字典？如果列表可以增长，它们是一个好主意吗？
将它们放在常量中意味着需要重新编译代码以进行小的更改。作为解决方案，我会避开它。
将它们放入数据库意味着您需要进行更多的数据库调用或实施缓存策略。如果需要，将描述本地化为不同的语言也有点困难。这两种方法各有利弊，但最终它们都是可行的解决方案。

【解决方案3】：

这通常也称为 One True Lookup Table (OTLT) - 请参阅我的旧博客条目 OTLT and EAV: the two big design mistakes all beginners make。

【讨论】：