我正在开发一个小型内容管理系统，其中的数据是高度相关的。我从一个小的抽象开始，但我可能会选择一个完整的实体属性值模型。然而，我突然想到，我是在关系数据库 (pgsql) 上构建所有这些，在这样一个强大的引擎之上重建模型没有任何意义。
虽然这不是很常见，这让我觉得有人已经想到了这一点，这可能是一个陷阱。有人可以向我解释在应用程序中创建和更改表以表示您的用户可自定义数据模型的注意事项吗？
【问题讨论】：
标签： mysql database-design architecture entity-attribute-value
我假设您已经了解了 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 文档中。
【讨论】：