Optymalna struktura DB dla dodatkowych pól encji

Question

Mam tabelę w bazie danych (opartej na PostgreSQL), która działa jak nadklasa w programowaniu obiektowym. Ma kolumnę "typ", która określa, które dodatkowe kolumny powinny być obecne w tabeli (właściwości podklasy). Ale nie chcę, aby tabela zawierała wszystkie możliwe kolumny (wszystkie właściwości wszystkich możliwych typów).

Postanowiłem więc utworzyć tabelę zawierającą kolumny "klucz" i "wartość" (np. "Nazwa pliku" = "/ plik" lub "wartość_wartość" = "5"), które zawierają dowolną możliwą własność obiekt, nieuwzględniony w tabeli nadklas. Stworzyłem także jedną powiązaną tabelę zawierającą dostępne wartości "klucza".

Ale jest problem z taką architekturą - kolumna "wartość" powinna być domyślnie typu danych ciąg, aby móc cokolwiek zawrzeć. Ale nie sądzę, że konwersja do i od strun jest dobrą decyzją. Jaki jest najlepszy sposób na ominięcie tego ograniczenia?

Answer 1

Projekt, z którym eksperymentujesz, jest odmianą Entity-Attribute-Value i ma wiele problemów i nieefektywności. To nie jest dobre rozwiązanie dla tego, co robisz, chyba że w ostateczności.

Co może być lepszym rozwiązaniem jest to, co opisuje fallen888: utwórz tabelę "podtypu" dla każdego z podtypów. Jest to w porządku, jeśli masz skończoną liczbę podtypów, co brzmi jak to, co masz. Następnie atrybuty specyficzne dla podtypów mogą zawierać typy danych, a także, jeśli to konieczne, ograniczenie NOT NULL, co jest niemożliwe, jeśli korzystasz z projektu EAV.

Jednym z pozostałych słabych punktów konstrukcji podtypu jest to, że nie można wymusić istnienia wiersza w tabeli podtypów tylko dlatego, że główny wiersz w tablicy nadklasy mówi, że powinien. Ale to słabsza słabość niż te wprowadzone przez projekt EAV.

edytuj: Jeśli chodzi o dodatkowe informacje na temat komentarzy do dowolnej jednostki, to jest to dość powszechny wzorzec. Uważaj na zepsute rozwiązanie zwane "polimorficznym skojarzeniem", które jest techniką stosowaną przez wiele osób w tej sytuacji.

Answer 2

Jedyne obejście (zachowując swój strucure) ma mieć osobne tabele:

create table IntProps(...); 
create table StringProps(...); 
create table CurrencyProps(...); 

Ale nie sądzę, że jest to dobry pomysł ...

Answer 3

Jedno wspólne podejście jest posiadanie tabela klucz-wartość zawiera wiele kolumn, po jednym dla każdego typu danych, np. StringValue, DecimalValue itp.

Wystarczy wiedzieć, że handlujesz zapytaniami i wydajnością dla schematu bazy danych, którego nie potrzebujesz zmieniać. Można również rozważyć mapowanie ORM lub bazę danych obiektów.

Answer 4

Co powiecie na to ... każdy podtyp otrzymuje swoją własną tabelę DB. A baza/super tabela ma właśnie kolumnę varchar zawierającą nazwę tabeli podtypu DB. Wtedy można mieć coś takiego ...

Entity 
------ 
ID 
Name 
Type 
SubTypeName (value of this column will be 'Dog') 


Dog 
--- 
VetName 
VetNumber 
etc 

Jeśli nie chcesz, aby (pod) nazwy tabeli jako wartości varchar w tabeli bazowej, można też po prostu mieć tabeli podtypu której klucz podstawowy będzie w tabeli bazowej.

Answer 5

Możesz mieć tabelę kluczy/wartości dla każdego typu. Dostępna tabela musiałaby kodować dostępność konkretnej pary klucz/typ, aby wskazywała poprawnie wpisaną tabelę klucz/wartość.

Wydaje się to jednak wysoce nieefektywną architekturą dla opartych na wierszach relacyjnych baz danych.

Być może powinieneś rzucić okiem na zorientowaną na kolumny relacyjną bazę danych?

Answer 6

Dzięki za odpowiedzi. Wyjaśnię trochę bardziej szczegółowo, czego potrzebuję. Istnieje potrzeba zaprogramowania witryny blogu i forum, a ja sprawdzałem numer WordPress DB structure.

Istnieje silna potrzeba umieszczania komentarzy w dowolnym rodzaju "obiektu", takiego jak wpis na blogu lub załącznik do pliku wideo. Powyższa struktura DB, która jest bardzo łatwa do skalowania i do spełnienia wszystkich naszych potrzeb, była powodem jej wyboru.

Ale to nie jest za późno, aby to zmienić, bo jest to na etapie wczesnej inżynierii. Również nasz model pachnie teraz jak DB oparty całkowicie na hierarchii drzew. Na razie przyjmuję Bill Karwin's and fallen888 answers, ale może idę w zupełnie niewłaściwym kierunku?

Answer 7

o czym użytkownik może dodać nowe pole do tabeli:

którą podziwiam tych wszystkich ludzi dokonywania komentarzy.

Kiedyś interesowałem się tego typu rzeczami kilka lat temu, ale napisałem ostatnio mały kod (poza odrobiną PHP i MYSQL).

Myślę, że to dobrze, jeśli chcesz iść dalej - możesz skończyć z czymś nowym.

Przepraszamy za przelewanie zimnej wody do systemu - podziwiam twoje wysiłki. Moim osobistym przeświadczeniem jest to, że jeśli posuniesz się wystarczająco daleko w tym kierunku, otrzymasz system, który interpretuje więcej języka naturalnego niż SQL. (Około 1970 r. SQL został napisany w języku Sequel i faktycznie oznaczało "uporządkowany angielski język zapytań", ale po ich ujednoliceniu w latach siedemdziesiątych - myślę, że ktoś powiedział, że Oracle był pierwszą komercyjną implementacją, 19079, "angielski" odpadły, bo sądzę, że zdecydowały, że to tylko mały podzbiór języka angielskiego:

W tej okolicy skończyło mi się trochę, bo nie mam pracy Bez prostej pracy, która płaci rachunki, gdzie mogę eksperymentować z tych pomysłów, to trochę trudno skoncentrować się na tym obszarze.

Najlepsze życzenia dla wszystkich.

Answer 8

przepraszam, pisałem 19079 powyżej, miałem na myśli rok 1979. Oracle dostał swój pierwszy kontrakt nakaz baza danych dla CIA.