我在用您的术语时遇到麻烦。您正在描述一个EAV结构（代表Entity-Attribute-Value）。
另外：“面向列”数据库通常是指将每一列与其他列分开存储的数据库（当我了解数据库时，这被称为“垂直分区”，但我认为这并不流行）。示例包括Paracel和Vertica。
特定结构的第一个问题是键入。一些属性是字符串，一些属性是数字。这成为EAV世界中的管理梦night。您要么将所有内容存储为字符串（失去键入检查值的能力并保证算术单词），要么将类型不同的多个列包含在类型列中（使查询复杂得多）。
同样，约束和外键引用很难实现。另外，由于您要在每一行上重复实体ID和属性ID，因此数据通常会占用更多空间。 NULL值通常非常节省空间。
在OLTP方面，您还有另一个问题。当您要插入实体时，通常还希望插入一堆属性。现在，一个插入已变成许多插入，您将需要开始将它们包装在事务中，从而影响性能。
考虑到所有这些缺点，您可能会认为 永远不要 使用EAV模型。有一个适合他们的地方。当属性随时间变化时，它们特别有用。说，如果您有一个应用程序，用户可以在其中添加带有标签的自己的信息。在这种情况下，混合方法是最佳解决方案。使用包含许多列的常规关系表来获取公共信息。将EAV表用于每个实体的可选信息。
602392714
清零编程群