Det största problemet jag har med PostgreSQL:s INHERITS implementering är att du inte kan ställa in en främmande nyckelreferens till den överordnade tabellen. Det finns många fall där du behöver göra det. Se exemplen i slutet av mitt svar.
Beslutet att skapa tabeller, vyer eller utlösare utanför Rails är det avgörande. När du väl bestämt dig för att göra det tror jag att du lika gärna kan använda den bästa strukturen du kan hitta.
Jag har länge använt en basöverordnad tabell, som upprätthåller disjunkta undertyper med hjälp av främmande nycklar. Denna struktur garanterar att endast en association kan existera och att associationen löser sig till rätt undertyp i den överordnade tabellen. (I Bill Karwins bildspel om SQL-antimönster , detta tillvägagångssätt börjar på bild 46.) Detta kräver inte utlösare i de enkla fallen, men jag tillhandahåller vanligtvis en uppdateringsbar vy per undertyp och kräver klientkod för att använda vyerna. I PostgreSQL kräver uppdateringsbara vyer att man skriver antingen utlösare eller regler. (Version före 9.1 kräver regler.)
I det mest allmänna fallet har de disjunkta undertyperna inte samma antal eller typ av attribut. Det är därför jag gillar uppdateringsbara vyer.
Bordsarv är inte bärbart, men den här typen av struktur är det. Du kan till och med implementera det i MySQL. I MySQL måste du ersätta CHECK-begränsningarna med referenser för främmande nyckel till enradstabeller. (MySQL analyserar och ignorerar CHECK-begränsningar.)
Jag tror inte att du behöver oroa dig för dataduplicering. För det första är jag ganska säker på att data inte dupliceras mellan överordnade tabeller och ärvda tabeller. Det ser bara ut så. För det andra, duplicering eller härledd data vars integritet är helt kontrollerad av dbms är inte ett särskilt bittert piller att svälja. (Men okontrollerad dubbelarbete är.)
Fundera lite på om borttagningar ska överlappa.
- Ett exempel på publikationer med SQL-kod.
- En exempel på "partier" med SQL-kod.