Kniha Craiga Larmana „Applying UML with Patterns“ popisuje 3 běžná řešení tohoto problému.
Vaše příklady nejsou nijak zvlášť užitečné – neexistuje žádný logický důvod mít 3 různé způsoby správy jména osoby ve vaší databázi (i když se to pravidelně stává kvůli podivnosti importu/exportu dat).
Je však velmi běžné, že existuje entita „osoba“, která může být zaměstnancem (s zamestnanec_id), kontaktem (s odkazem na tabulku potenciálních zákazníků) nebo zákazníkem (s customer_id a odkazem na tabulku objednávek). .
V Larmanově knize uvádí 3 řešení.
Jeden stůl bude vládnout všem Zde vytvoříte jednu tabulku se všemi známými sloupci. To vytváří chaotickou tabulku a přenáší odpovědnost za znalost pravidel zachování každé podtřídy na aplikační vrstvu – databáze nebude vyžadovat, aby zákazníci měli customer_id. Nicméně to dělá spojení mnohem jednodušší - jakákoli tabulka, která potřebuje odkaz na osobu, se může jednoduše propojit s tabulkou osob.
Tabulka supertřídy Tím se věci vyčistí extrahováním společných atributů do jedné tabulky - např. "person" - a vloží pole specifická pro podtřídu do tabulek podtříd. Takže můžete mít jako tabulku nadtřídy „osoba“ a tabulky „kontakt“, „zaměstnanec“ a „zákazník“ s konkrétními daty podtřídy. Tabulky podtříd mají sloupec "person_id" pro propojení zpět s tabulkou nadtřídy. To je složitější - obvykle to vyžaduje další spojení při načítání dat - ale také mnohem méně náchylné k chybám - nemůžete náhodně poškodit datový model chybou, která zapisuje neplatné atributy pro "zaměstnance".
Tabulka podle podtřídy - to je to, co jsi popsal. Zavádí to do datového modelu značné množství duplikace a často máte podmíněná spojení – „připojit se k tabulce x, pokud typ osoby =y“, což může zkomplikovat kód pro přístup k datům.