База данных, ориентированная на столбцы, и база данных, ориентированная на строки

Я долгое время пользовался ориентированным на строки проектированием баз данных, и, за исключением проектов хранилищ данных и примеров больших данных, я не использовал проектирование ориентированных на столбцы баз данных для приложения OLTP.

Моя таблица, ориентированная на строки, выглядит так

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

Некоторые люди в нашей команде отстаивают дизайн баз данных, ориентированный на столбцы. Они предполагают, что все имена столбцов должны быть именами свойств в таблице свойств. Тогда другая таблица 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).

Похоже, мы идем к настоящей проблеме. Колонно-ориентированный дизайн хорошо принят в отрасли.

Ответы на вопрос(5)

Ваш ответ на вопрос