Datenbank für Mitgliederverwaltung in einem Verein

verwendetes Datenbanksystem: <sql server>
Hallo Zusammen,
Ich möchte eine Datenbank entwerfen für eine Applikation um die Mitglieder in einem verein (Sprachschule) zu verwalten. Ich habe schon angefangen in visual studio 2019 (code first) die klassen zu erstellen und möchte daraus die Datenbank erstellen mit entity framework.

Ich habe folgende Klassen:
-Mitglied hat alle Informationen und eine Funktion (Lehrer, Verwaltung, Schüler, Keine), hat Beziehung zum Kurs
-Hauptmitglied : Mitglied -> kann der Vater von Schüler (Familienmitglieder) in der Schule, Lehrer oder Verwaltung sein. kann Beziehung zu Schüler haben, oder selbst ein Schüler, wenn er erwachsen ist.
-Familienmitglied : Mitglied -> ist meistens Schüler
-Kurs hat Beziehung zum Schüler und zum Lehrer
-Beitrag hat Beziehung zum Hauptmitglied

wo ich Hilfe brauche oder Fragen habe, ist:
soll ich für Mitglieder eine einzige Tabelle/Klasse machen und dort unterscheiden zwischen Hauptmitglieder und Familienmitglieder oder wie ich gemacht habe mit Vererbung.

wie würdet ihr das machen?
Danke für eure Meinungen

Ich persönlich würde bei EF nicht mit Vererbung arbeiten, sondern lieber mit optionalen 1:1 Entitäten oder sogar noch einer Abstraktionsebene mehr (je nach deinen Anforderungen).

Ich hatte das einmal in einem Projekt und es macht es unheimlich schwierig die Datenbank "von Hand" anzuschauen, weil - je nach gewählten Schema für die Vererbung - mehrere Tabellen entstehen.
Ich weiß aktuell nicht einmal ob EFCore Vererbung schon kann.

Bei Optionalen 1:1 Entitäten könntest du für jede Funktion (Rollen) eine eigene Entität anlegen und diese auf ein Mitglied referenzieren lassen. Das hätte den Vorteil, wenn mal jemand zwei Funktionen (Rollen) hat, du dies auch abbilden kannst.
Ob das so notwendig und richtig ist, hängt natürlich von deinen Anforderungen ab - das kannst du nur selber beantworten - wenn du keine Eigenschaften hast, die nur ein Lehrer hat, ist das so ggf. nicht sinnvoll.

EF Core unterstützt derzeit nur TPH (Table-Per-Hierarchy), TPT (Table-Per-Type) soll noch kommen, mehr dazu hier und hier ein Vergleich der drei Vererbungs-Strategien.

Bei TPH bekommst Du eine Tabelle für alle Ableitungen der selben Hierarchie raus, zusammen mit einer Property/Spalte, die angibt, zu welcher Klasse die Daten gemappt werden sollen. Somit hast Du dann nur eine Tabelle für alles, allerdings auch viele Spalten, die je nach Situation ungenutzt sind.
Was das "manuelle" Anschauen von der Datenbank angeht, macht das mMn. kaum einen Unterschied, solange man weiß, was das für Daten sind.

EF6 würde ich ganz allgemein nicht mehr nutzen, aber das ist zu einem großen Teil mein persönlicher Geschmackt.
Gegen TPH-Ableitung habe ich jedenfalls nichts, wenn man die Ableitung tatsächlich braucht, kann das sogar sehr angenehm sein, aber man sollte sich schon sicher sein, bevor man es nutzt.

In jedem Fall ist es klüger, erst auf die klassischen Varianten zu bauen, jede Form von Ableitung ist gleichzeitig auch eine extrem starke Abhängigkeit zwischen den Klassen, das sollte man sich sehr gut überlegen.

Du könntest dir auch überlegen, ob Du die Aufteilung überhaupt brauchst?
Was unterscheidet Haupt- und Familien-Mitglied so sehr, dass sich eine Trennung auf Datenbank-Ebene lohnt? Wenn die Unterschiede gering sind, dann würde ich die komplett zusammen fassen und dann ein Enum daneben legen, was die Art darstellt.
Das wäre auch ungefähr das, was bei TPH generiert werden würde, nur ohne zusätzliche Vererbung.