Twoja sprawa wygląda jak instancja klasy/podklasy.
Istnieją dwa klasyczne sposoby projektowania tabel SQL do obsługi podklas. Każdy ma zalety i wady.
Jeden ze sposobów nazywa się „dziedziczeniem jednotabelowym”. W tym projekcie jest tylko jedna tabela dla wszystkich typów użytkowników. Jeśli dana kolumna nie dotyczy danego wiersza, przecięcie jest pozostawione NULL. Można dodać kolumnę, aby wskazać typ użytkownika.
Inny sposób nazywa się „Dziedziczeniem tabeli klas”. Przypomina to odpowiedź, której udzielił Nanego, z kilkoma drobnymi zmianami. Jest jedna tabela dla użytkowników, ze wszystkimi wspólnymi danymi i polem identyfikacyjnym. Dla każdej podklasy istnieje jedna tabela z danymi dotyczącymi tej podklasy. Pole identyfikatora jest często konfigurowane jako kopia pola identyfikatora w pasującym wierszu w tabeli użytkowników. W ten sposób klucz podklasy może pełnić podwójną funkcję, działając zarówno jako klucz podstawowy, jak i jako klucz obcy odwołujący się do tabeli użytkownika. Ta ostatnia technika nazywa się „Wspólnym kluczem podstawowym”. Wymaga trochę programowania podczas wstawiania, ale warto. Wymusza charakter relacji jeden-do-jednego i przyspiesza niezbędne połączenia.
Możesz wyszukać wszystkie trzy projekty jako tagi w SO lub jako artykuły w Internecie.
single-table-inheritance class-table-inheritance shared-primary-key
