Проблемът тук е подтипът . Има три основни подхода за справяне с подтиповете.
- Поставете всеки тип запис в напълно отделна таблица;
- Поставете запис в родителска таблица и след това запис в таблица на подтип; и
- Поставете всички записи в една таблица, като има колони с нула за „незадължителните“ данни (т.е. неща, които не се отнасят за този тип).
Всяка стратегия има своите предимства.
Например, (3) е особено приложимо, ако има малка или никаква разлика между различните подтипове. Във вашия случай различните регистрационни записи имат ли допълнителни колони, ако са от определен тип? Ако не го направят или има няколко случая, когато го правят, поставянето на всички в една таблица е напълно логично.
(2) обикновено се използва за парти маса. Това е често срещан модел в CRM, който включва обект родителска страна, който има подтипове за лице и организация (организацията може също да има подтипове като компания, асоциация и т.н.). Лицето и Организацията имат различни свойства (напр. поздрав, дадени имена, дата на раждане и т.н. за Лице), така че има смисъл да ги разделите, вместо да използвате колони с нула.
(2) е потенциално по-ефективен от пространството (въпреки че режийните разходи за NULL колони в съвременните СУБД са много ниски). По-големият проблем е, че (2) може да бъде по-объркващо за разработчиците. Ще получите ситуация, в която някой трябва да съхрани някъде допълнително поле и ще го удари в колона, която е празна за този тип, просто защото е по-лесно да направите това, отколкото да получите одобрение за DBA да добавя колона (не, не се шегувам ).
(1) е може би най-рядко използваната схема от 3-те според моя опит.
И накрая, трябва да се има предвид мащабируемостта и вероятно е най-добрият случай за (1). В определени моменти JOIN не се мащабират ефективно и ще трябва да използвате някаква схема за разделяне, за да намалите размерите на таблицата си. (1) е един от методите за това (но груб метод).
Все пак не бих се тревожил много за това. Обикновено ще трябва да стигнете до стотици милиони или милиарди записи, преди това да стане проблем (освен ако вашите записи не са наистина големи, в този случай това ще се случи по-рано).
