Największy problem, jaki mam z INHERITS w PostgreSQL implementacja polega na tym, że nie można ustawić odniesienia klucza obcego do tabeli nadrzędnej. Jest dużo przypadków, w których musisz to zrobić. Zobacz przykłady na końcu mojej odpowiedzi.
Decyzja o utworzeniu tabel, widoków lub wyzwalaczy poza Railsami jest kluczowa. Kiedy zdecydujesz się to zrobić, myślę, że równie dobrze możesz użyć najlepszej struktury, jaką możesz znaleźć.
Od dawna używam podstawowej tabeli nadrzędnej, wymuszając rozłączne podtypy za pomocą kluczy obcych. Ta struktura gwarantuje, że może istnieć tylko jedna asocjacja i że asocjacja jest rozpoznawana do odpowiedniego podtypu w tabeli nadrzędnej. (W pokazie slajdów Billa Karwina na temat antywzorców SQL , to podejście rozpoczyna się na slajdzie 46.) Nie wymaga to wyzwalaczy w prostych przypadkach, ale zwykle udostępniam jeden aktualizowalny widok na podtyp i wymagam kodu klienta do korzystania z widoków. W PostgreSQL aktualizowalne widoki wymagają napisania wyzwalaczy lub reguł. (Wersje wcześniejsze niż 9.1 wymagają reguł).
W najbardziej ogólnym przypadku rozłączne podtypy nie mają tej samej liczby ani rodzaju atrybutów. Dlatego lubię widoki, które można aktualizować.
Dziedziczenie tabel nie jest przenośne, ale tego rodzaju struktura jest. Możesz go nawet zaimplementować w MySQL. W MySQL musisz zastąpić ograniczenia CHECK odniesieniami do kluczy obcych do tabel jednowierszowych. (MySQL analizuje i ignoruje ograniczenia CHECK.)
Myślę, że nie musisz się martwić o powielanie danych. Po pierwsze, jestem prawie pewien, że dane nie są duplikowane między tabelami nadrzędnymi i tabelami dziedziczącymi. Po prostu tak się wydaje. Po drugie, duplikacja lub dane pochodne, których integralność jest całkowicie kontrolowana przez dbms, nie są szczególnie gorzką pigułką do przełknięcia. (Ale niekontrolowane duplikacja jest.)
Zastanów się, czy usuwanie powinno być kaskadowe.
- przykład publikacji z kodem SQL.
- Przykład "imprezy" z kodem SQL.
