我正在开发一个小型的内容管理系统，并且其中的数据高度相关。我从一个小的抽象开始，但是我可能要使用完整的实体-属性-值模型。但是，我想到我将所有这些都建立在关系数据库（pgsql）上，并且在像这样的强大引擎之上重建模型没有任何意义。
但是，这不是很常见，这使我认为有人已经想到了这一点，这可能是一个陷阱。有人可以向我解释在应用程序内部创建和更改表以表示您的用户可定制数据模型的注意事项吗？
最佳答案
我认为您已经了解了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文档中。
关于mysql - EAV与直接操作表的警告？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/47314522/