sql - 面向列的数据库与面向行的数据库

Question

我长期使用面向行的数据库设计，除了数据仓库项目和大数据示例，我没有为 OLTP 应用程序使用面向列的数据库设计。

我的面向行的表格看起来像

ID, Make, Model, Month, Miles, Cost
1   BMW   Z3     12     12000  100

我们团队中的一些人提倡面向列的数据库设计。他们建议所有的列名都应该是 Property 表中的属性名。然后另一个表 Quote 将有两列 PropertyName 和 PropertyValue。

在 .net 代码中，我们读取每个键并比较并转换为强类型对象。代码真的越来越乱了。

if (qwi.DomainCode == typeof(CoreBO.Base.iQQConstants.MBPCollateralInfo).Name)
     {
        if (qwi.RefCode == iQQConstants.MBPCollateralInfo.ENGINETYPE)
        {
           Aspiration = qwi.Value;
        }
        else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.FUELTYPE)
        {
           FuelType = qwi.Value;
        }
        else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.MAKE)
        {
           Make = qwi.Value;
        }
        else if (qwi.RefCode == iQQConstants.MBPCollateralInfo.MILEAGE)
        {
           int reading = 0;
           bool success = int.TryParse(qwi.Value, out reading);
           if (success)
           {
              OdometerReading = reading;
           }
}
}

这种面向列的设计的论据是我们不必更改表架构和存储过程(我们仍在使用存储过程而不是 Entity Framework )。

看来我们正在进入真正的问题。面向列的设计是否在业界得到广泛接受。

Answer 1

我对您的术语有疑问。您正在描述一个 EAV 结构(代表 Entity-Attribute-Value)。

旁白:“面向列”的数据库通常指的是将每一列与其他列分开存储的数据库(当我学习数据库时，这被称为“垂直分区”，但我认为这并不流行)。示例包括 Paracel 和 Vertica。

实体属性值数据库将实体的每个属性存储为单独的行。

您的特定结构遇到的第一个问题是打字。有些属性是字符串，有些是数字。这成为 EAV 世界中的管理噩梦。要么将所有内容存储为字符串(失去键入检查值和保证算术字的能力)，要么将不同类型的多个列包含在一个类型列中(使查询更加复杂)。

同样，约束和外键引用更难实现。此外，由于您在每一行中重复实体 ID 和属性 ID，因此数据通常会占用更多空间。 NULL 值通常非常节省空间。

在 OLTP 方面，您还有另一个问题。当你想插入一个实体时，你通常也想插入一堆属性。一次插入现在变成了多次插入，您会希望开始将它们包装在事务中，这会影响性能。

考虑到所有这些缺点，您可能认为从不使用 EAV 模型。他们有一个地方。当属性随时间变化时，它们特别有用。比如说，如果您有一个应用程序，用户可以在其中使用标签输入他们自己的信息。在这种情况下，混合方法是最佳解决方案。使用包含许多列的常规关系表来获取公共(public)信息。使用 EAV 表获取每个实体的可选信息。