Problémem je podtypování . Existují tři základní přístupy k zacházení s podtypy.
- Umístěte každý typ záznamu do zcela samostatné tabulky;
- Umístěte záznam do nadřazené tabulky a poté záznam do tabulky podtypů; a
- Umístěte všechny záznamy do jedné tabulky se sloupci s možnou hodnotou Null pro "volitelná" data (tj. věci, které se na tento typ nevztahují).
Každá strategie má své výhody.
Například (3) je zvláště použitelné, pokud je mezi různými podtypy malý nebo žádný rozdíl. Mají ve vašem případě různé záznamy protokolu další sloupce, pokud jsou určitého typu? Pokud tomu tak není, nebo existuje jen málo případů, kdy to dělají, dát je všechny do jedné tabulky dává dokonalý smysl.
(2) se běžně používá pro stůl Party. Toto je běžný model v CRM, který zahrnuje nadřazený objekt strany, který má podtypy pro osobu a organizaci (Organizace může mít také podtypy jako společnost, sdružení atd.). Osoba a organizace mají různé vlastnosti (např. pozdrav, křestní jména, datum narození atd. pro osobu), takže je rozumné je rozdělit, spíše než používat sloupce s možností null.
(2) je potenciálně prostorově efektivnější (ačkoli režie sloupců NULL v moderních DBMS je velmi nízká). Větší problém je, že (2) může být pro vývojáře více matoucí. Dostanete se do situace, kdy někdo potřebuje někde uložit další pole a nabourá ho do sloupce, který je pro tento typ prázdný, jednoduše proto, že je to jednodušší, než získat souhlas pro DBA k přidání sloupce (ne, nedělám si legraci ).
(1) je podle mých zkušeností pravděpodobně nejméně často používané schéma ze 3.
Nakonec je třeba zvážit škálovatelnost a je pravděpodobně nejlepším případem pro (1). V určitých bodech se JOINy neškálují efektivně a budete muset použít nějaké schéma rozdělení, abyste snížili velikost tabulky. (1) je jedna z metod, jak toho dosáhnout (ale hrubá metoda).
Moc bych si s tím ale hlavu nelámal. Obvykle se budete muset dostat ke stovkám milionů nebo miliardám záznamů, než se to stane problémem (pokud vaše záznamy nejsou opravdu velké, v takovém případě se to stane dříve).