Database design 数据库设计：灵活性与简单性

我正试图权衡一个简单数据库结构的相对利弊，例如：

一,

vs:

二,

其中属性类型可以是blah或blah

选项1提供了简单性-表格更易于读/写；选项2提供了灵活性（如果我们想添加另一个属性，如blah_blah_blah，我们不需要进行模式更改，因此可能需要更少的代码更改）

这个难题有正确/错误的答案吗？其中一个选项被认为比其他选项更好吗？你能告诉我进一步的阅读可能有助于确定前进的方向吗？

我几乎总是选择#1-我只是更喜欢将属性作为表中的列-使查询、性能索引和一般处理更容易、更透明

#2选项称为EAV-Entity-Attribute-Value，它有一些主要缺点，请参阅

• -EAV方法在此列表中为#3

---

几乎每次都是选项1。选择2的效率非常低。当您必须使用更高效的方法进行某些操作时，轻松查询也是相当笨拙的。话虽如此，我已经看到了许多针对用户定义属性的产品。使用选项2技术的系统示例包括和

如果您正在开发一个定制的应用程序，那么添加属性的最佳方法就是在需要时扩展数据库模式。由于变更将伴随着对代码的修改，因此可以将其作为发布过程的一部分来完成

如果您正在开发一个打包的应用程序，希望客户自行配置，那么您可以采取三种广泛的方法

EAV结构类似于选项2。这很灵活，但查询效率很低，特别是当查询由于多个联接而变得复杂时

在表上创建一组“用户”字段（User1、User2等）。这将您限制为一个有限的数字，但这个数字可能相当大（如果需要，您可以使用User01-User99）。然而，它是最有效和最简单的查询。另一个缺点是字段有点不透明。您必须访问配置信息才能了解“User3”的含义。它还牺牲了一些类型安全性。但是，总的来说，您的用户字段机制将拥有一些自己的元数据和某种类型的通用框架，因此可以通过它提供一些类型安全性。

这看起来最不雅观，但在大多数情况下是最好的方法，因为它具有最好的性能和最简单的查询。这是迄今为止最容易处理的方案

XML。这是非常灵活的，但是围绕数据库的大多数工具在处理XML方面做得很差。它还将XML存储在与主表不同的分配单元中，因此可能会导致查询性能出现重大问题。基于XML的策略非常以应用程序为中心，而牺牲了数据的其他消费者。

根据我的经验，在数据库的XML字段中存储大量数据将显著增加应用程序的TCO。在大多数情况下，不建议将其用于用户数据字段

---

有趣的是，您没有提到性能或数据完整性。值得一提的是，模型1是考虑这些因素的最佳方法

就数据模型而言，灵活性被大大高估了。大多数表结构在开发之初是众所周知的，并且在数据库的整个生命周期中保持稳定。如果您有一个应用程序，其中的模型是真正的流体和不可知的，那么您可能根本不应该使用RDBMS。请选择一种NoSQL产品

这是对#1的又一次投票。

@marc#u s 我不相信人们“几乎总是”能在上述选项中做出任何选择。有一个案例支持这两种解决方案

选项1 当实体X定义得很好时，也就是说，您确切地知道为了定义X需要捕获什么。在这种情况下，一条X记录几乎可以捕获X实例代表的所有内容

选项2 当这样一个实体X不能完全定义时，也就是说，你不知道需要什么集合属性来“完全”定义它

---

例如，以“应避免的五个简单数据库设计错误”一文中提到的员工记录为例[链接由@marc_提供]。对你会被吸引到第1选项，但是如果你考虑在大型组织中工作的雇员，一旦记录了员工信息——它的定义和内容都是高度动态的，并且选项1和选项2的组合需要。p> 每个解决方案都有一个问题要解决#1是一个很好的方法，如果你知道你需要的栏目。但是，在某些情况下，这些列在前面是未知的。例如，用户添加到功能的自定义字段

话虽如此，EAV有很多问题。在国际海事组织，如果使用得当，它们是有用的

确保不要为所有内容创建EAV。仅适用于“未知项目”

请记住，EAV没有依赖的外键关系

由于非平凡的查询，性能较低，并且维护可能更复杂

请记住，EAV必须旋转以使其有意义（通常是这样）

---

如前所述，这取决于您的需求。仅当需要添加新类型的属性作为程序工作流的一部分时，才应选择#2。在表中添加新列肯定比在查询中添加一个额外的表和一个额外的联接更糟糕。

@marc\s

虽然我提到了员工记录的例子，但我相信这不是很有说服力

以下是来自金融领域的示例

如果你

CREATE TABLE x (
    my_id INT PRIMARY KEY,
    ...,
    text_attribute_blah TEXT,
    text_attribute_blah_blah TEXT
);

CREATE TABLE x (
    my_id INT PRIMARY KEY,
    ...
)

CREATE TABLE attributes (
    my_id INT,  /* foreign key to x.my_id */
    text_attribute_type INT,
    text_attribute TEXT
)