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