mysql - EAV 与直接表操作的注意事项？

Question

我正在开发一个小型内容管理系统，其中的数据关系密切。我从一个小的抽象开始，但我可能会选择一个完整的实体属性值模型。然而，我突然想到，我正在关系数据库(pgsql)上构建所有这些，并且在这样强大的引擎之上重建模型没有任何意义。

但这并不常见，这让我觉得有人已经想到了这一点，这可能是一个陷阱。有人可以向我解释在应用程序内创建和更改表以表示用户可自定义的数据模型的注意事项吗？

Answer 1

我假设您已经了解了 EAV 的所有缺点。

您在描述您想要实现的目标时非常简洁，所以我会猜测 - 您想要某种方式来允许您的开发人员和/或内容管理员定义模式，并允许软件进行推理关于基于该模式的数据。例如，show all entities of type 'article' belonging to category 'architecture' in status 'published' order by 'publication_date' descending .

如果您有关系模型并且在编写查询时知道属性类型，那么编写查询就很容易。

使用 EAV 编写查询非常困难。

如果您事先不知道属性，那么在关系模型中编写查询也是一个困难 - 您基本上必须在域模型和关系数据库之间编写一个转换层。我曾使用过执行此操作的 CMS 系统，它们通常施加的限制是“仅向前”的更改。您可以添加属性，但不能删除或更改它们。

这是因为数据库是最简单的 - 它将数据模式映射到域模型很困难，并且它们使用的生成器非常擅长添加新属性，但在重命名事物或更改数据类型时会感到非常困惑，或删除它们。例如，如果您删除属性“publication_date”，则必须检查所有生成的文件以查看它是否发生，然后根据这些方法等传递查找方法。

编辑:

您写道，您希望内容管理员创建新实体以及这些实体之间的关系。总而言之，关系数据库在这方面并不擅长。最接近的相似之处是对象关系映射工具，其目的是从与之通信的面向对象应用程序中抽象出底层数据库。 ORM 坚定地针对开发人员，而不是最终用户，并引入了自己的认知开销；它们往往工作得很好，直到您遇到极端情况。

您可能会考虑使用面向文档的解决方案(MySQL 本身支持 XML 和 JSON)。您失去了纯关系模型的一些验证和可扩展性功能，但获得了很多简单性。例如，您可能有一个名为“content_item”的表，其中包含适用于所有内容项的所有固定属性，并允许您实现工作流逻辑，但将内容本身存储在 content_item 表内的 JSON 文档中。