Největší problém mám s INHERITS PostgreSQL implementace spočívá v tom, že nemůžete nastavit odkaz na cizí klíč na nadřazenou tabulku. Je jich spousta případů, kdy to musíte udělat. Podívejte se na příklady na konci mé odpovědi.
Rozhodnutí vytvořit tabulky, pohledy nebo spouštěče mimo Rails je zásadní. Jakmile se pro to rozhodnete, pak si myslím, že byste také mohli použít tu nejlepší strukturu, jakou můžete najít.
Dlouho jsem používal základní rodičovskou tabulku, vynucující nesouvislé podtypy pomocí cizích klíčů. Tato struktura zaručuje, že může existovat pouze jedno přidružení a že se přidružení překládá na správný podtyp v nadřazené tabulce. (V slideshow Billa Karwina o antivzorcích SQL , tento přístup začíná na snímku 46.) V jednoduchých případech to nevyžaduje spouštěče, ale obvykle poskytuji jeden aktualizovatelný pohled na podtyp a pro použití pohledů požaduji klientský kód. V PostgreSQL vyžadují aktualizovatelná zobrazení zapsání spouštěčů nebo pravidel. (Verze starší než 9.1 vyžadují pravidla.)
V nejobecnějším případě disjunktní podtypy nemají stejný počet nebo druh atributů. Proto mám rád aktualizovatelná zobrazení.
Dědičnost tabulky není přenosná, ale tento druh struktury ano. Můžete to dokonce implementovat v MySQL. V MySQL musíte omezení CHECK nahradit odkazy na cizí klíč na jednořádkové tabulky. (MySQL analyzuje a ignoruje omezení CHECK.)
Myslím, že se nemusíte bát duplikace dat. Za prvé, jsem si docela jistý, že se data mezi nadřazenými tabulkami a dědícími tabulkami neduplikují. Jen se to tak jeví. Na druhém místě duplikace nebo odvozená data, jejichž integrita je zcela řízena dbms, nejsou zvlášť hořkou pilulkou ke spolknutí. (Ale nekontrolovaně duplikace je.)
Zamyslete se nad tím, zda by mazání mělo probíhat kaskádovitě.
- příklad publikace s kódem SQL.
- A příklad "strany" s kódem SQL.