Eu tenho usado design de banco de dados orientado a linha por muito tempo e, exceto para projetos de datawarehouse e amostras de Big Data, eu não usei design de banco de dados orientado por colunas para o aplicativo OLTP.

Minha tabela orientada por linha parece

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

Algumas pessoas em nossa equipe defendem o design de banco de dados orientado por colunas. Eles sugerem que todos os nomes de coluna devem ser nomes de propriedades em uma tabela de propriedades. Em seguida, outra tabela Quote terá duas colunas PropertyName e PropertyValue.

No código .net, lemos cada chave e comparamos e convertemos em objeto fortemente tipado. O código está realmente ficando confuso.

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;
           }
}
}

O argumento para esse design orientado a colunas é que não teremos que alterar o esquema da tabela e o procedimento armazenado (ainda estamos usando o procedimento armazenado em vez do Entity Framework).

Parece que estamos nos encaminhando para um problema real. O design orientado por colunas é bem aceito na indústria.