Il problema più grande che ho con INHERITS di PostgreSQL l'implementazione è che non è possibile impostare un riferimento di chiave esterna alla tabella padre. Ce ne sono molti molti dei casi in cui è necessario farlo. Vedi gli esempi alla fine della mia risposta.
La decisione di creare tabelle, viste o trigger al di fuori di Rails è cruciale. Una volta deciso di farlo, penso che potresti anche usare la migliore struttura che puoi trovare.
Ho usato a lungo una tabella padre di base, applicando sottotipi disgiunti usando chiavi esterne. Questa struttura garantisce che possa esistere solo un'associazione e che l'associazione si risolva nel sottotipo corretto nella tabella padre. (In nella presentazione di Bill Karwin sugli antipattern SQL , questo approccio inizia nella diapositiva 46.) Ciò non richiede trigger nei casi semplici, ma di solito fornisco una vista aggiornabile per sottotipo e richiedo al codice client di utilizzare le viste. In PostgreSQL, le viste aggiornabili richiedono la scrittura di trigger o regole. (Le versioni precedenti alla 9.1 richiedono regole.)
Nel caso più generale, i sottotipi disgiunti non hanno lo stesso numero o tipo di attributi. Ecco perché mi piacciono le viste aggiornabili.
L'ereditarietà delle tabelle non è portabile, ma questo tipo di struttura lo è. Puoi persino implementarlo in MySQL. In MySQL, devi sostituire i vincoli CHECK con riferimenti di chiave esterna a tabelle a una riga. (MySQL analizza e ignora i vincoli CHECK.)
Non penso che tu debba preoccuparti della duplicazione dei dati. In primo luogo, sono abbastanza sicuro che i dati non siano duplicati tra le tabelle padre e le tabelle ereditarie. Sembra proprio così. In secondo luogo, la duplicazione o i dati derivati la cui integrità è completamente controllata dal dbms non è una pillola particolarmente amara da ingoiare. (Ma incontrollato la duplicazione è.)
Pensa se le eliminazioni debbano essere eseguite a cascata.
- Un esempio di pubblicazioni con codice SQL.
- Un esempio di "parti" con codice SQL.
