数据库设计——一张表多字段，多表一字段，还是抽象表？答案

【问题标题】：Database design - one table with many fields, many tables with one field, or abstract tables?数据库设计——一张表多字段，多表一字段，还是抽象表？
【发布时间】：2011-04-24 06:38:34
【问题描述】：

我必须设计一个模式来存储具有许多属性但很少有共同点的对象。

我在这里找到了一些解决方案，但我仍然不相信最好的办法。我看到了四种方法：

一张表有很多字段：这可能会导致很多NULL 值，并且在需要添加一些属性或修改一些数据类型时会遇到困难。
为每个属性创建一个新表：这使得添加和更新列变得容易，并保留了搜索功能，尽管每个 SELECT 都会产生很多 JOIN。
为每个 type 属性创建一个表，例如：标签、数量、间隔等。我不确定在这种情况下是否需要区分浮点数、小数、整数等。
创建抽象表（我在这里读到它称为观察模式），用于存储属性名称和数据类型。

我应该遵循哪些标准，我应该回答哪些问题才能在这些解决方案之间进行选择？

谢谢

【问题讨论】：

您是否考虑过为此使用document database 而不是关系？
“视情况而定。”对于“开发人员控制的架构”，我将继续使用 #1，除非有 已证明需要 走其他路线之一（将 volatile 用户定义的字典映射到表列通常是＃1的双输，但考虑稀疏列等）。应该注意“亲吻”和“只做谨慎的事”。

标签： design-patterns database-design orm custom-fields

【解决方案1】：

我想说这取决于您使用的 ORM 技术和对象的序列化能力。

一般来说，我更喜欢抽象和灵活性。

【讨论】：

【解决方案2】：

这取决于您需要对这些属性做什么。如果属性只是间接感兴趣，那么 4 是一个非常灵活和紧凑的解决方案。我所说的间接利益是什么意思？如果您需要检索和显示属性中的信息，这是间接的。如果您需要对属性进行计算或详细操作，那么这更直接。换句话说，如果您可能在属性上使用的唯一方法是“.ToString()”，那么您可以使用 4。此架构具有显着优势，允许您在不更改数据库的情况下添加新的属性类型架构，因为这些只是插入到您的属性类型表中的新行。

另一方面，如果不同的属性类型需要以依赖于它们的数据类型的方式进行操作，那么将不同类型的属性存储在一个字段中将会很痛苦。如果是这种情况，您可以执行 3.，但这也是一个问题，因为它需要您知道要转到哪个表来获取特定类型的值。这不是一个无法克服的问题，但也不是优雅的。

您可以尝试一种混合方法，而不是 3。在这种方法中，您的单个属性表有多个列，每个数据类型一个列，最好还有一个其他列 - 可能是计算列 - 充当“ToString”。通过这种方式，您的间接使用可以转到简单、可预测的位置，并且只有涉及更多的应用程序才需要担心针对特定属性类型应该转到哪一列。

【讨论】：