Най-големият проблем, който имам с INHERITS
на PostgreSQL реализацията е, че не можете да зададете препратка към външен ключ към родителската таблица. Има много от случаите, в които трябва да направите това. Вижте примерите в края на моя отговор.
Решението за създаване на таблици, изгледи или тригери извън Rails е решаващото. След като решите да направите това, мисля, че можете да използвате най-добрата структура, която можете да намерите.
Отдавна използвам базова родителска таблица, налагайки несвързани подтипове с помощта на външни ключове. Тази структура гарантира, че може да съществува само една асоциация и че асоциацията се разрешава до правилния подтип в родителската таблица. (В слайдшоуто на Бил Карвин за SQL antipatterns , този подход започва на слайд 46.) Това не изисква тригери в простите случаи, но обикновено предоставям един обновяем изглед на подтип и изисквам клиентски код за използване на изгледите. В PostgreSQL актуализираните изгледи изискват писане на тригери или правила. (Версиите преди 9.1 изискват правила.)
В най-общия случай несвързаните подтипове нямат същия брой или вид атрибути. Ето защо харесвам изгледи с възможност за актуализиране.
Наследяването на таблицата не е преносимо, но този вид структура е. Можете дори да го внедрите в MySQL. В MySQL трябва да замените ограниченията CHECK с препратки към външни ключове към таблици с един ред. (MySQL анализира и игнорира ограниченията CHECK.)
Не мисля, че трябва да се притеснявате за дублиране на данни. На първо място, почти съм сигурен, че данните не се дублират между родителските таблици и наследяващите таблици. Просто изглежда така. На второ място, дублиране или извлечените данни, чиято цялост се контролира напълно от dbms, не е особено горчив хап за преглъщане. (Но неконтролирано дублирането е.)
Помислете дали изтриванията трябва да бъдат каскадни.
- Пример за публикации със SQL код.
- пример за "партии" със SQL код.