Przez długi czas korzystałem z projektowania baz danych zorientowanych na rzędy, a poza projektami datawarehouse i Big data sample, nie korzystałem z projektu bazy danych z kolumną dla aplikacji OLTP.Baza zorientowana na kolumnę a baza zorientowana na wiersz
Moja zorientowane wiersz tabeli wygląda
ID, Make, Model, Month, Miles, Cost
1 BMW Z3 12 12000 100
Niektórzy ludzie w naszym zespole opowiada kolumny zorientowane bazy danych projektu. Sugerują one, że wszystkie nazwy kolumn powinny być nazwami właściwości w tabeli Właściwość. Następnie inna tabela Cytat będzie miał dwie kolumny Nazwa właściwości i Wartość właściwości.
W kodzie .net czytamy każdy klucz i porównujemy i konwertujemy na obiekt silnie wpisany. Kod jest naprawdę brudny.
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;
}
}
}
arguement dla tej kolumny zorientowanych projektu jest to, że nie będzie musiał zmienić schemat tabeli i przechowywanej proc (nadal jesteśmy przy użyciu przechowywanej proc zamiast Entity Framework).
Wygląda na to, że zmierzamy do prawdziwego problemu. Czy projektowanie zorientowane na kolumnę jest dobrze akceptowane w branży.
Wygląda na to, że pytanie nie ma nic wspólnego z DBMS zorientowanymi na kolumny (magazyn kolumnowy). Pytanie dotyczy właśnie wzoru projektu EAV. – sqlvogel
"wciąż używamy zapisanego proca zamiast Entity Framework" Grałem z EF w wielu mniejszych i średnich projektach i nie myślę już, że EF jest drogą do zrobienia. Z tego, co przetestowałem i rozumiem, EF musi mieć dane w pamięci, aby móc nimi manipulować (tzn. Aktualizować), które często blokują drzwi, gdy rozważana jest poważna praca. – Mariusz
„my nadal używa przechowywanej proc zamiast Entity Framework” EF wydaje się potrzebne dane w pamięci, aby móc je modyfikować, więc coś tak prostego jak: UPDATE dbo.MyTable SET Aktywny = 1, gdzie aktywny = 0 za dużą ilość danych może nie być trywialnie za pomocą EF (ale uwielbiam to również, gdy kopie tyłek na duży czas) – Mariusz