我正在开发一个包含页面/帖子、自定义页面/帖子和自定义字段的 CMS。这些自定义字段将通过 UI 选择并附加到自定义页面。
例如，我们创建了一个自定义页面/帖子“项目”，其中包含以下字段：描述、订单、价格和日期。
我不想为我拥有的每种页面类型使用一个表，我只想使用一个表来存储每个给定自定义字段的每个字段，问题是它们可能具有不同的数据类型。 我的问题是，存储例如是否是一个坏主意（考虑性能）？通用长文本类型字段中的订单值？创建一个包含 3 个字段（日期、整数、文本）的“customvaluestable”是否更好，该字段根据其数据类型存储 customfield 的值并将其余部分留空？
谢谢
【问题讨论】：
标签： mysql database database-design entity-attribute-value database-optimization
从技术上讲，这是一个坏主意……实际上，这两种想法都可以。您可能认为“我不想一直修改表格”，但有一些含义：搜索字符串的效率低于搜索数字、日期等...如果要将所有内容放入文本字段，不仅会不会占用更多空间，搜索都是字符串搜索。
您应该问自己的是：它是什么，您真正想要实现的目标是什么？如果您希望将一些额外的 任意 数据与静态数据一起存储，那么您将不会像以往那样搜索... json-encode 该数据并将其放入您称为“customdata”的字段中管他呢。或者使用 nosql / keyvalue-store 开始！
当您想搜索它时，请加倍努力，看看 drupal 如何处理自定义字段。这很丑陋，但至少它们是一致的。数字应存储在数字字段中。 （因为数字的字典顺序在字符串字段中真的很奇怪......）。
【讨论】：
您可能希望改用 MySQL 5.7 及其对 native JSON data type 的新支持。然后你就可以拥有你的自定义字段了。
您所说的设计称为Entity-Attribute-Value model。尽管我对它实际上是否有资格作为数据模型提出异议。
EAV 存在许多问题，因为它基本上是在关系数据库中实现的非关系解决方案。
有用的阅读：
但最重要的是，您基本上最终会创建自己的关于列和类型的元数据系统——基本上，在 RDBMS 中实现自己的数据库管理系统，这需要大量工作并引入大量一路上的错误。这被称为Inner-platform Effect：
... 软件架构师倾向于创建一个可定制的系统，从而成为他们正在使用的软件开发平台的复制品，而且通常是糟糕的复制品。
【讨论】：