database - EAV - Hybrid 是一个糟糕的数据库设计选择

Question

我们必须将遗留的 POI 数据库从 MySQL 重新设计为 PostgreSQL。目前，所有实体都有 80-120 多个代表各个属性的属性。

我们被要求考虑新数据库的灵 active 和良好的设计方法。然而，新设计应该允许:

• n 没有。任何实体的属性/特性，即任何实体的属性都不是固定的，可能会定期更改。

• 允许内容管理员通过管理界面即时向现有实体添加新属性，而不是一直在数据库架构中进行更改。

关于 EAV 的性能问题有很多讨论，但如果我们不使用混合 EAV，我们最终会:

• 有很多空列(即使 99% 的数据没有这些属性，我们仍然会添加新列)
• 花更多时间维护数据库，尤其是。当属性不断变化时。
• 不允许内容管理员向现有实体添加新属性

无论如何，这就是我们对新设计的想法(包括基本的 ERD):

• 每个实体都有单独的表格，其中包含一些独有的基本信息，例如id,name,address,contact,created,etc.

• 有 2 个表属性类型和属性来存储属性信息。

• 使用多对多关系将每个实体链接到一个属性。

• 在不同的表中存储地址并使用外键链接到实体。

我们认为这将使我们在添加、删除或更新属性时更加灵活。

但是，这种设计会导致获取数据时连接的数量增加，例如，要显示给定体育场的所有“属性”，我们可能会有一个包含 20 多个连接的查询，以在一行中获取所有相关属性。

您对这个设计有什么看法，您有什么改进建议。

感谢阅读。

Answer 1

我正在维护一个已有 10 年历史的系统，该系统的中央 EAV 模型包含 10M+ 实体、500M+ 值和数百个属性。我的一些设计注意事项:

如果您有任何适用于特定属性的业务逻辑，那么将该属性作为显式列是值得的。 EAV 属性实际上应该是通用的东西，应用程序不应该区分属性 A 和属性 B。如果您在代码中找到对 EAV 属性的文字引用，很可能它应该是一个明确的列。

拥有大量空列并不是一个大的技术问题。它确实需要良好的编码和文档实践来区分最终出现在一张表中的不同问题:

• 制定约定和规则，让您知道应用程序的哪一部分读取和修改了数据的哪一部分。
• 使用 View 来简化使用调试工具对数据库的检查。
• 创建和维护测试数据生成器，以便您可以轻松地为您当前不感兴趣的模型部分创建符合架构的虚拟数据。
• 使用严格的数据库版本控制。进行架构更改的唯一方法应该是通过跟踪和应用更改脚本的工具。 Postgresql 具有事务性 DDL，这是自动化架构更改的一项 killer 级功能。

Postgresql 并不真正喜欢瘦表。除了遍历所有行以将数据放在一起的额外工作之外，每个属性值都会产生 32 字节的数据存储开销。如果您主要是批量读取和写入属性，请考虑以某种方式将数据序列化到行中。 attr_ids int[], attr_values text[] 是一个选项，hstore 是另一个选项，或者客户端的东西，比如 json 或 protobuf，如果你不需要触及数据库端的任何特定内容。

不要特意将所有内容都放入一个实体表中。如果它们不以合理的方式共享任何属性，请使用您使用的特定 EAV 模式的多个实例。但是一定要尝试使用相同的模式并在不同实例之间共享任何访问器代码。您始终可以对实体名称的代码进行参数化。

永远记住，代码就是数据，数据就是代码。您需要在将决策插入元模型和将它们表示为代码之间找到正确的平衡点。如果你让元模型做太多事情，修改它需要与你的代码相同的理解系统、版本控制工具、QA 程序、暂存的能力，但它没有任何工具。从本质上讲，您将使用一种非常笨拙的非标准语言进行编程。另一方面，如果您在代码中留下太多内容，那么每一个微不足道的更改都需要您的软件的新版本。人们往往会犯错误，让元模型过于复杂。为元模型构建开发人员工具是一项艰巨而乏味的工作，而且 yield 有限。另一方面，通过自动化从提交到部署发生的所有事情来降低发布过程的成本有很多附带好处。