假设我有一个产品表，其中将保留一些字段，所有其他属性都是用户生成的可空列。
(reserved)
__
/ \
/ \
--------------------------------------
| id | name | color | height | width |
--------------------------------------
与EAV一样，它将允许任意数量的属性，但属性也是可查询的。这种方法的潜在缺点是什么？
如果用户在ADD/DROP COLUMN语句中控制的唯一内容是字段名称（总是经过验证以防止删除保留字段），我们是否可以排除安全问题？
当表格变得非常大时，ADD/DROP COLUMN语句会变得多么昂贵？假设我们有速率限制以避免用户滥用系统。
从性能角度来看，单个表中有多少（可为空，无索引）列太多了？
答案 0 :(得分：3)
使用键/值对的第二个表格会好得多。
是什么让你认为第二种表方法不可查询？
DDL语句不能在事务中。它可能取决于您正在使用的数据库引擎，但如果DDL必须等到每个其他事务完成，并且/或它将在等待其他事务完成时阻止所有其他事务，我不会感到惊讶。换句话说，表现会很糟糕。
答案 1 :(得分：0)
在运行时为关系数据库动态修改模式是非常昂贵的，并且通常会产生一些不良影响（不是为了释放东西和吃孩子，而是关闭;）
所以我会看两个选择。
保留不同类型的通用字段名称，配置数据库映射用户选择使用这些额外字段的内容，以便在自定义报告流程中有适当的列标题等（我已经看过这个用于多个ERP软件包中。）
考虑使用允许存储不同对象的非关系数据库（通常使用JSON等）
答案 2 :(得分：0)
如何创建包含属性键值对的第二个表，并使用product表的外键，而不是向现有表添加列？这将允许产品的任何数量和种类的属性，并且可以通过加入主键 - 外键上的表来轻松查询。
答案 3 :(得分：0)
在生产中修改数据库模式是一件令人头疼的事。 用户修改数据库模式是当有人用卡车把你拉过来然后备份并再次打你时，你会感到头痛。
用户在正常业务处理期间添加到数据库的信息（包括新属性的名称）是数据，而不是架构信息，应该这样处理。