Sie sprechen über die Implementierung von Polymorphie, die zwar nicht in einer relationalen Datenbank möglich ist, aber eine gute Möglichkeit ist, die Vor- und Nachteile zu beurteilen. Option 1 ähnelt der Unterklasse, bei der das Kreditkonto alles vom Konto erbt und erweitert. Verwenden Sie das also, wenn Sie möchten, dass das Konto eine Oberklasse ist ... mit anderen Worten, wenn Sie eine neue Art von Konto hinzufügen, z. B. Kreditkarte, fügen Sie eine weitere Tabelle hinzu und beziehen sich auch auf das Konto. Das bedeutet, dass die Kontentabelle generisch bleiben muss ... Kontonummer, Kontostand usw.
Option 2 behandelt die beiden Arten von Konten wie separate Klassen. Verwenden Sie das, wenn sie nicht viele CRUD-Operationen teilen, da jetzt eine einfache Kontostandaktualisierung als Antwort auf eine Transaktion irgendwo anderen Code haben muss.
Option 3 ist der allgemeine Ansatz. Ein großer Vorteil ist die einfache Modellierung und Abfrage. Es ist ein großer Nachteil, dass Sie keine NOT NULL-Einschränkungen für Spalten implementieren können, die für einige Kontotypen aber nicht für andere vorhanden sein müssen.
Es gibt eine vierte Option, um die ersten beiden Optionen zu kombinieren, die eine ähnliche Lösung wie die Parteiabstraktion für Personen und Organisationen bietet. Sie haben 3 Tabellen: 1) eine Account-Tabelle, die die grundlegenden Elemente von Konto-ID, Kontostand, Besitzer usw. behandelt; 2) eine Kreditkontentabelle, die die zusätzlichen Spalten und einen Verweis auf die Konto-ID aufweist; und 3) eine einfache Account-Tabelle, die nur einen Verweis auf die Account-ID hat. Dies mag wie Overkill erscheinen, aber es richtet ein System ein, das Sie ohne Änderung erweitern können. Ich habe das Muster oft benutzt.