Tabela "Dziedziczenie" w SQL Server

Question

Obecnie analizuję naszą bazę danych do zarządzania kontaktami i chciałem usłyszeć opinie ludzi na temat rozwiązania problemu wielu typów kontaktów mających wspólne atrybuty.

Zasadniczo mamy 6 typów kontaktów, które obejmują osobę, firmę i stanowisko @ firma.

W obecnej strukturze wszystkie mają adres, jednak w tabeli adresów należy zapisać ich typ, aby dołączyć do kontaktu.

Ten spójny wymóg dołączania do typu kontaktu po pewnym czasie staje się frustrujący.

Dzisiaj natknąłem się na post omawiający "Dziedziczenie tabeli" (http://www.sqlteam.com/article/implementing-table-inheritance-in-sql-server).

Zasadniczo istnieje tabela nadrzędna i wiele podtablic (w tym przypadku każdy typ kontaktu). Stamtąd wymuszasz integralność, aby tabela podrzędna musiała mieć wzorzec główny, gdzie zdefiniowany jest typ.

Sposób, w jaki go widzę, dzięki tej metodzie nie będę już musiał zapisywać typu w tabelach takich jak adres, ponieważ identyfikator jest unikalny we wszystkich typach.

Po prostu chciałem się dowiedzieć, czy ktoś ma jakiekolwiek uczucia odnośnie tej metody, czy jest to dobry sposób, czy może alternatywa?

Używam programu SQL Server 05 & 08 powinien to mieć znaczenie.

Dzięki

Ed

Answer 1

wciąż masz problem, że jeśli chcesz pola podtyp i masz tylko styk główny, trzeba wiedzieć, co tabela iść patrząc na - lub przyłącz się do nich wszystkich. W przeciwnym razie jest to praktyczne rozwiązanie dla wspólnego problemu.

Inną możliwością (dość podobną w strukturze, ale różną w twoim sposobie myślenia) jest po prostu umieszczenie wszystkich kontaktów w jednym stole. Następnie dla bardziej szczegółowych pól (birthday dla osób i department dla pozycji @ firma) utwórz oddzielne tabele powiązane z tym kontaktem.

 
    Contact Table 
    -------------- 
    Name 
    Phone Number 

    Address Table 
    ------------- 
    Street/state, etc 
    ContactId 

    ContactBirthday Table 
    -------------- 
    Birthday 
    ContactId 

    Departments Table 
    ----------------- 
    Department 
    ContactId 

To wymaga innego sposobu myślenia o rzeczach, choć - zamiast myślenia ludzi kontra firm myślisz o różnych wymagań funkcjonalnych dla danego zadania - jeśli chcesz wysłać kartki urodzinowe, dostać wszystkie kontakty, które mają urodziny z nimi związane, itp.

Answer 2

Wiem, że to niewiele pomoże, ale początkowo lepiej byłoby mieć tabelę jednostek niż 6 różnych typów kontaktów. Wtedy każda Jednostka może mieć tyle adresów ile potrzeba i nie będzie potrzeby wpisywania w łączeniu.

Answer 3

Mam zamiar wyjść tutaj na kończynę i zasugerować, że należy przemyśleć swoją strategię normalizacji (ponieważ wydaje się, że masz dość szczęścia, aby móc całkowicie przemyśleć swój schemat). Jeśli zwykle przechowujesz adres dla każdego kontaktu, to tablica kontaktów powinna zawierać pola adresu. Ewentualnie, jeśli adres jest przechowywany w firmie, adres powinien być zapisany w tabeli firmy i kontakty powiązane z tą firmą.

Jeśli kontakty mają tylko jeden adres lub jedną (lub nawet 3, tylko nie "wiele") instancji innych pól, pomyśl o racjonalizacji ich w jednej tabeli. Z mojego doświadczenia wynika, że ​​posiadanie kilku pól zerowych jest o wiele lepszą alternatywą niż konieczność pozostawienia złączeń dla danych, które nie są pewne.

Na szczęście dla każdego, kto gwałtownie się ze mną nie zgadza, prosiłeś o opinie! :) IMHO powinieneś znormalizować tylko wtedy, gdy potrzebujesz . W przypadku ponownego przemyślenia schematów, denormalizacja powinna być rozważana przy każdej okazji.

Answer 4

Gdy masz siódmy typ, musisz utworzyć kolejną tabelę.

Answer 5

Zaprojektowałem bazę danych, podobnie jak sugerowany przez ciebie link. Chodziło o przechowywanie danych dla wielu różnych raportów technicznych. Liczba typów raportów jest niezdefiniowana i prawdopodobnie wzrośnie do około 40 różnych typów.

Utworzyłem jedną tabelę raportu głównego, która ma główny klucz autocenzury. Ta tabela zawiera wszystkie popularne informacje, takie jak klient, strona testowa, wyposażenie, data itd.

Następnie mam jedną tabelę dla każdego typu raportu, który zawiera informacje ogólne dotyczące tego typu raportu. Ta tabela ma ten sam klucz podstawowy co master i odwołuje się również do wzorca.

Mój pomysł na podzielenie tego na różne tabele z relacją 1: 1 (która normalnie byłaby nie-nie) polegałby na uniknięciu jednego pojedynczego stołu z ogromną liczbą kolumn, co bardzo trudno byłoby utrzymać jako ciągle dodając kolumny.

Mój projekt z dziedziczeniem tabel dał mi segmentowane dane i możliwości rozbudowy bez trudu utrzymania. Jedyne, co musiałem zrobić, to napisać specjalną specjalną metodę zapisu, która automatycznie obsługuje pisanie do dwóch tabel. Do tej pory jestem bardzo zadowolony z projektu i nie znalazłem żadnych wad, z wyjątkiem nieco bardziej skomplikowanej metody zapisu.

Answer 6

Google na temat "modelowania relacyjnego gen-spec". Znajdziesz wiele artykułów omawiających dokładnie ten wzór. Niektóre z nich koncentrują się na projektowaniu tabel, podczas gdy inne koncentrują się na podejściu obiektowym.

Dziedziczenie tabeli pojawia się w kilku z nich.

Answer 7

Spróbuję tego podejścia. Tak, musisz utworzyć nowe tabele, gdy masz nowy typ, ale ponieważ ta tabela będzie prawdopodobnie miała inne kolumny, to i tak to się stanie, jeśli nie użyjesz tego schematu.

Jeśli tabele dziedziczące wzorce nie różnią się zbytnio od siebie, polecam wypróbowanie innego podejścia.

Answer 8

Mogę zasugerować, abyśmy po prostu dodali tabelę typów. Tj. Osoba ma adres, imię itp., A następnie uczeń, nauczyciel, ponieważ każdy przypadek użycia przedstawia siebie, mamy tabelę PersonType, która ma wpis z tabeli osób do n typów, a kolejne nowe tabele nauczyciel, obcy, piosenkarz jako system eveolves ...