一个表来统治他们所有

将每个“产品”放入一个表中，生成每一列并使用此怪物表。

临：

轻松查询
简易布局

缺点：

很多NULL值
实际代码对查询变得敏感（不同类型，需要不同的列）

EAV-模式

显然，EAV-Pattern可以为此提供更好的解决方案。但是，我过去一直在使用EAV，当涉及到性能时，它可能成为大量条目的问题。

搜索很简单，但列出“规范化表格”需要每个实际列一次加入 - ＆gt;慢。

临：

清洁
弹性

缺点：

性能
未规范化

每个类别的单个表

基本上与EAV模式相反：每个产品类型创建一个表，即“猫”，“狗”，“汽车”，......

虽然这可能适用于相当数量的类别，但如果你必须维持这些类别，那么对于稳定增长的类别来说，这是一场噩梦。

临：

清洁
性能

缺点：

维护
查询-管理

两全其美

所以，在我的互联网之旅中，我找到了混合两种方法的建议：使用单个表格来获取常用信息，同时将其他属性分组为以EAV-Fashion组织的“属性组”。

但是，我认为，这基本上会导致每种方法的缺点......您需要使用常规表（基本信息）并进行大量连接以获取所有信息。

在JSON / XML中存储增强信息

另一种方法是将extendet信息存储在JSON / XML格式条目中（在“根表”的列中）。

但是，我并不喜欢这样，因为查询和使用它比使用常规数据库布局更难（呃）。

自动化单个表

另一个想法是自动化每个类别“创建表”的部分（因此自动化查询），同时维护一个只包含id和类别信息的“主表”，以获得最佳性能对于未确定数量的表...？

即：

Products
id | category | actualId
1  | cat      | 1
2  | car      | 1

cats
id | color | mew
1  | white | true

cars
id | wheels | bhp
1  | 4      | 123

（摘要）Product表允许查询所有内容，而详细信息可通过与“actualId”和负责人表的简单连接获得。

但是，如果要运行“show all”查询，这会导致问题，因为单独的SQL无法解决此问题，因为表名（在连接中）需要在查询中显式。

还有哪些其他选项？有很多“网上商店”，每个都或多或少地处理这个问题 - 他们如何以有效的方式解决它？

Answer 1

我非常不同意你的观点，即“怪物”表方法会导致“简单查询”，而EAV方法会导致性能问题（过早优化？）。它不需要复杂的查询：

SELECT base.id, base.other_attributes,
, GROUP_CONCAT(CONCATENATE(ext.key, '[', ext.type, ']',  ext.value)) 
FROM base_attributes base
LEFT JOIN  extended_attributes ext
ON base.id=ext.id
WHERE base.id=?
;

你需要对上面的内容进行一些解析，但是一点点抛光会给出一些可以解析的东西，如JSON或XML ，而不会将你的数据放在匿名blob中

如果您不关心数据完整性并且乐于通过复制来解决性能问题，那么NoSQL就是可行的方法（这与使用JSON或XML存储数据完全相同）。

EAV vs null vs Mixed