Przez długi czas korzystałem z projektowania baz danych zorientowanych na wiersze i poza projektami hurtowni danych i próbkami Big Data, nie korzystałem z projektowania baz danych w oparciu o kolumny dla aplikacji OLTP.

Moja tabela zorientowana na rząd wygląda

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

Niektórzy ludzie w naszym zespole opowiadają się za projektowaniem baz danych w oparciu o kolumny. Sugerują, że wszystkie nazwy kolumn powinny być nazwami właściwości w tabeli Property. Następnie kolejna tabela Quote będzie miała dwie kolumny PropertyName i PropertyValue.

W kodzie .net czytamy każdy klucz i porównujemy i konwertujemy na silnie typowany obiekt. Kod naprawdę się psuje.

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

Argumentem dla tego projektu zorientowanego na kolumny jest to, że nie będziemy musieli zmieniać schematu tabel i zapisanego proc (nadal używamy zapisanego proc zamiast Entity Framework).

Wygląda na to, że zmierzamy w prawdziwy problem. Czy projekt zorientowany na kolumny jest dobrze przyjęty w branży.