我目前正在为电子商务平台的产品部分设计数据库结构 . 它需要以这样的方式设计，使得可以销售具有无限多个不同属性的无限数量的不同类型的产品 .
例如 . 笔记本电脑的属性可以是RAM，屏幕尺寸，重量等 . 书的属性可以是作者，ISBN，出版商等 .
似乎EAV结构最合适 .
-
选择产品
-
产品属于属性集
-
属性集包含属性x和y
-
属性x是数据类型datetime（存储在attribute_values_datetime中的值）
-
属性y是数据类型int（存储在attribute_values_int中的值）
-
每个属性定义表示类型（i，e，x具有列类型 - > datetype）
假设如上所述，我可以将选择加入attribute_values_datetime表以获取正确的数据而不获取结果集并在表已知的情况下构建第二个查询吗？构建这种类型的查询会有很大的性能影响，或者下面的内容会更合适（虽然功能较少）
-
选择产品
-
产品属于属性集
-
属性集包含属性x和y
-
属性x是数据类型datetime，但在attribute_values中存储为TEXT
-
属性y是数据类型int，但在attribute_values中存储为TEXT
3 回答
我将对这个问题的大多数评论提出相反的意见 . 虽然EAV是EVIL的原因，你可以在SO和DBA.SE以及其他地方找到很多次的详细解释，但是有一个非常常见的应用，其中大多数EAV错误的东西在很大程度上是无关紧要的（很少）EAV的优点是非常密切相关的 . 该应用程序是在线产品目录 .
EAV的主要问题是它不会让数据库做它真正擅长的事情，这有助于通过将它们安排在模式中来为不同实体的信息的不同属性提供适当的上下文 . 拥有模式可以在访问，解释和实施数据完整性方面带来许多优势 .
关于产品目录的事实是产品的属性几乎完全与目录系统本身无关 . 产品目录系统（最多）使用产品属性做三件事 .
以列表形式向最终用户显示列表中的产品属性：： .
在比较网格中显示多个产品的属性，其中不同产品的属性相互排列（产品通常是列，属性通常是行）
基于特定属性/值组合来推动某些事物的规则（例如定价） .
如果你的系统所做的只是在语义上与系统无关的反刍信息，那么这些信息的模式基本上没有用 . 事实上，模式会妨碍在线产品目录，特别是如果您的目录中有许多不同类型的产品，因为您总是不得不重新使用模式来修改它以允许新的产品类别或属性类型 .
由于它的使用方式，即使产品目录中属性值的数据类型也不一定（非常重要） . 对于某些属性，您可能需要施加约束，例如“必须是数字”或“必须来自此列表” . 这取决于属性一致性对您的目录的重要程度以及您希望实现的详细程度 . 看看几家在线零售商的产品目录，我会说大多数人都准备在简单性方面进行权衡 .
是的，EAV是邪恶的，除非它不是 .
是的，在组装EAV模型的查询时通常会有很大的损失 . 检查数据的自我一致性会有更大的性能损失，因为DBMS无法为您执行此操作 . 如果出现问题，DBMS无法告诉您 .
根据评论中Oded的建议，使用更正统的数据库设计，DBMS可确保数据库中的数据更加一致 . 我强烈建议使用常规（非EAV）设计 .
我不知道这应该是评论还是回答 . 不过我走了 .
我不确切地知道你在建造什么 . 但你有没有看过Magento EAV database structure？是的，它可能很慢，查询可能很大，但对我们来说，优势不仅仅是减号 . 而另一方面，magento负责查询 .
我们正在迁移我们的在线商店（中大型商店）以使用Magento，现在我们对EAV方法非常满意 .