Projekt schematu bazy danych dla dużej liczby kolumn

Question

Mam przypadek użycia, w którym muszę modelować dane referencyjne dla np. różne smaki lodów. Powiedzmy, że mam 50 smaków lodów: -

• 20 atrybutów np. temperatura zamarzania, kremowość będą wspólne dla wszystkich smaków
• każdy smak lodów ma 20-30 atrybutów, które nie będą dzielone z innymi smakami, np. : -
  • truskawkowe lody mogą śledzić cierpkość, owoce procent itd
  • czekoladowe lody mogą śledzić poziom goryczy, kakao itp

Jak bym Model ten zgrabnie danych w bazie danych model, wyłącznie z punktu widzenia przechowywania/wyszukiwania?

Opcje można myślę: -

1. Jedna tabela na smaku. Będzie to wymagało 50 tabel, a każda tabela będzie miała 20 kolumn, które będą się nakładać na siebie, a kolejne 20-30 będzie atrybutem unikalnym dla smaku.
   • Plusy: modele danych każdego smaku całkiem dobrze
   • Wady: kolumna pokrywają i duża liczba tabel potrzebne
2. jedna tabela dla wszystkich smaków. Będzie to wymagało tylko 1 tabeli, ale będzie wymagało ponad 1000 kolumn, z których większość będzie pusta.
   • Plusy: Modele danych z lodami w ogóle, całkiem dobrze
   • Wady: duża liczba kolumn i znaczną kwotę „zmarnowane” przestrzeni
3. Jedna tabela klucz-wartość dla wszystkich smaków, z ID smaku, nazwa atrybutu i wartość atrybutu.
   • Zalety: najprostsze, aby utworzyć i wstawić dane
   • Minusy: trudniej wyodrębnić, nie naprawdę model danych per se, trudno tworzyć ograniczeń dla atrybutów, lub do atrybutów związanych z innymi atrybutami

Answer 1

Chciałbym mieć jedną tabelę ze wszystkimi wspólnymi atrybutami, a następnie inną dla atrybutów niewspólnych. Na przykład:

CREATE TABLE ICE_CREAM_FLAVOR 
    (FLAVOR   VARCHAR2(100) PRIMARY KEY, 
    FREEZING_TEMP NUMBER, 
    CREAMINESS  NUMBER, 
    ETC    VARCHAR2(25), 
    BLAH   NUMBER); 

CREATE TABLE ICE_CREAM_FLAVOR_ATTRIBUTE 
    (ID_ICF_ATTRIBUTE NUMBER, -- should be populated by an insert trigger 
    FLAVOR   VARCHAR2(100) 
    NOT NULL 
    REFERENCES ICE_CREAM_FLAVOR(FLAVOR), 
    ATTRIBUTE_NAME VARCHAR2(25), 
    ATTRIBUTE_VALUE VARCHAR2(100)); 

Twój przebieg może się różnić.

Udostępnij i ciesz się.

Answer 2

Chciałbym zasugerować, możesz utworzyć 3 różne tabele.

1. Smak lodów: Można przechowywać wszystkie smaki lodów. Będzie to tabela icecream_flavor_master. Powiedzmy, jeśli stworzysz 50 smaków niż 50 wierszy, takich jak truskawka, czekolada itp.

2. Cechy lodów: Możesz przechowywać wszystkie cechy lodów. Będzie to tabela icecream_attribute_master. Powiedzmy, że masz 50 atrybutów niż 50 wierszy, takich jak cierpkość, goryczka, procent owoców, poziom kakao itd.

3. Atrybuty lodów: W tej tabeli możesz zapisać klucz podstawowy icecream_flavor_master i icecream_attribute_master związek między smakiem a cechą lodów.

Proszę dać mi znać, aby uzyskać więcej informacji.

Answer 3

Nigdy nie przechowuj wartości w nieodpowiednim typie.

Cokolwiek wzór wybierzesz, upewnij się, że wartości są przechowywane w ich naturalnej formie. Użyj NUMBER, DATE, VARCHAR2, CLOB, XMLTYPE, CLOB (IS JSON), TIMESTAMP, itd. Próba zatłoczenia wszystkiego w ciągu spowoduje wiele problemów. Tracisz sprawdzanie poprawności, wygodę, wydajność i bezpieczeństwo typu.

Oto przykład typowego problemu związanego z bezpieczeństwem. Wyobraź sobie to proste zapytanie, aby znaleźć lody o zawartości większej niż 25%:

select * 
from ice_cream_flavor_attribute 
where attribute_name = 'Fruit Percentage' 
    and attribute_value > 25; 

Czy widzisz błąd? Czy widzisz, jak to samo zapytanie z tymi samymi danymi może zadziałać jeden dzień i nie powiedzie się następnym razem z ORA-01722: invalid number?

Trudno napisać zapytanie, które zmusza firmę Oracle do oceny warunków w określonej kolejności. Zmiana kolejności predykatów nie pomoże (99,9% czasu). Dodanie widoku śródliniowego nie pomoże (99,9% czasu). Używanie instrukcji CASE zadziała, ale nie w 100%. Korzystanie z podpowiedzi będzie działać, ale jest trudne. Używanie widoku śródliniowego i ROWNUM jest moim preferowanym sposobem rozwiązania problemu, ale wygląda dziwnie i jest trudny do zrozumienia.

---

Jeśli trzeba użyć modelu Atrybut Wartość jednostki (jeśli masz więcej niż 1000 atrybutów może okazać się nieuniknione), co najmniej używać odpowiednich typów.

Nie martw się o przestrzeń - kolumna pusta używa co najwyżej 1 bajta.

Nie przejmuj się reklamacjami typu "ale nasze zapytania są bardziej skomplikowane, zawsze musimy wiedzieć, której kolumny użyć!" - realistycznie nie ma nic użytecznego, co można zrobić z wartością bez znajomości jej typu. Za każdym razem, gdy czytasz lub piszesz wartość, musisz już myśleć o typie.

Answer 4

Być może możesz grupować smaki w klasy smaków, które mają pewne atrybuty. To nadaje się do klas i podklas, które rozszerzają inne klasy.

Jeśli chcesz wykonać modelowanie ER, wyszukaj "uogólnienie/specjalizację" w Internecie. Niektóre witryny nazywają to funkcją "Rozszerzonego modelowania ER" lub EER.

Aby zaprojektować tabele relacyjne w celu implementacji projektu ER, należy przyjrzeć się dwóm wzorom: Dziedziczenie z pojedynczą tabelą i Dziedziczenie z tabelą klas.
https://stackoverflow.com/tags/single-table-inheritance/info

https://stackoverflow.com/tags/class-table-inheritance/info

także zajrzeć do leczenia Martina Fowlera na ten temat w internecie, lub w jednej ze swoich książek.

Answer 5

Co wielcy producenci robią dla ogromnych danych w ECM (enterprise content management), gdzie mamy dość podobny scenariusz (wiele niestandardowych klas z niestandardowymi atrybutami, niektóre z nich mogą być takie same, mając różne typy nad atrybutami):

3. Jedna tabela klucz-wartość dla wszystkich smaków, z identyfikatorem smaku, nazwą atrybutu i wartością atrybutu.

Używają one jednej tabeli klucz-wartość dla każdego typu (ciąg, liczba, data itd.).

W celu optymalizacji wydajności pozwalają zdefiniować dedykowane tabele dla atrybutów, aby zachować mały indeks i nie wypełniać go innymi atrybutami.

stoły dedykowane sensu:

• Masywne użytkowania (mającego wiele wierszy)
• Bad histogramy (jak flagi)

Inaczej indeks Oracle może zostać oszukany, i pełny dostęp tabela najszybszy dostęp, który byłby naprawdę zły. Zacznij więc myśleć o wydajności przy dużej ilości danych.