Det største problem, jeg har med PostgreSQL's INHERITS implementering er, at du ikke kan angive en fremmednøglereference til den overordnede tabel. Der er masse af tilfælde, hvor du skal gøre det. Se eksemplerne i slutningen af mit svar.
Beslutningen om at oprette tabeller, visninger eller triggere uden for Rails er den afgørende. Når du først beslutter dig for at gøre det, så tror jeg, at du lige så godt kan bruge den allerbedste struktur, du kan finde.
Jeg har længe brugt en basisoverordnet tabel, der håndhæver usammenhængende undertyper ved hjælp af fremmednøgler. Denne struktur garanterer, at kun én tilknytning kan eksistere, og at tilknytningen løses til den rigtige undertype i den overordnede tabel. (I Bill Karwins diasshow om SQL-antimønstre , denne tilgang starter på slide 46.) Dette kræver ikke udløsere i de simple tilfælde, men jeg leverer normalt én opdaterbar visning pr. undertype og kræver klientkode for at bruge visningerne. I PostgreSQL kræver opdaterbare visninger skrivning af enten triggere eller regler. (Versioner før 9.1 kræver regler.)
I det mest generelle tilfælde har de usammenhængende undertyper ikke det samme antal eller samme slags attributter. Derfor kan jeg godt lide at opdatere visninger.
Bordarv er ikke bærbart, men denne form for struktur er det. Du kan endda implementere det i MySQL. I MySQL skal du erstatte CHECK-begrænsningerne med fremmednøglereferencer til tabeller med én række. (MySQL analyserer og ignorerer CHECK-begrænsninger.)
Jeg tror ikke, du skal bekymre dig om dataduplikering. For det første er jeg ret sikker på, at data ikke duplikeres mellem overordnede tabeller og nedarvede tabeller. Det ser bare sådan ud. For det andet duplikering eller afledte data, hvis integritet er fuldstændig kontrolleret af dbms, er ikke en særlig bitter pille at sluge. (Men ukontrolleret duplikering er.)
Tænk over, om sletninger skal kaskade.
- Et eksempel på publikationer med SQL-kode.
- En eksempel på "fester" med SQL-kode.