Ich habe lange Zeit das zeilenorientierte Datenbankdesign verwendet und abgesehen von Data Warehouse-Projekten und Big Data-Beispielen habe ich das spaltenorientierte Datenbankdesign für die OLTP-App nicht verwendet.

Meine zeilenorientierte Tabelle sieht aus wie

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

Einige Mitarbeiter unseres Teams befürworten ein spaltenorientiertes Datenbankdesign. Sie schlagen vor, dass alle Spaltennamen Eigenschaftsnamen in einer Eigenschaftstabelle sein sollten. Dann wird eine andere Tabelle Quote zwei Spalten PropertyName und PropertyValue haben.

Im .net-Code lesen wir jeden Schlüssel und vergleichen und konvertieren ihn in stark typisierte Objekte. Der Code wird wirklich unordentlich.

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

Das Argument für dieses spaltenorientierte Design ist, dass wir das Tabellenschema und den gespeicherten Prozess nicht ändern müssen (wir verwenden weiterhin den gespeicherten Prozess anstelle von Entity Framework).

Scheint, als stünden wir vor einem echten Problem. Ist spaltenorientiertes Design in der Branche gut akzeptiert?