Mein Rat zur Datenmodellierung lautet:
- Sie sollten allgemein optionale (nullable) Spalten 1:1-Joins vorziehen . Es gibt immer noch Fälle, in denen 1:1 sinnvoll ist, normalerweise dreht es sich um die Untertypisierung. Die Leute sind seltsamerweise zimperlicher, wenn es um nullable-Spalten geht als um Joins;
- Machen Sie nicht auch ein Modell indirekt, es sei denn wirklich gerechtfertigt (mehr dazu weiter unten);
- Favour tritt der Aggregation vor. Dies kann variieren, so dass es getestet werden muss. Siehe Oracle vs. MySQL vs. SQL Server:Aggregation vs Joins für ein Beispiel dafür;
- Joins sind besser als N+1-Selects. Eine N+1-Auswahl ist beispielsweise die Auswahl einer Bestellung aus einer Datenbanktabelle und die anschließende Ausgabe einer separaten Abfrage, um alle Einzelposten für diese Bestellung abzurufen;
- Die Skalierbarkeit von Joins ist normalerweise nur ein Problem, wenn Sie Massenauswahlen durchführen. Wenn Sie eine einzelne Zeile auswählen und diese dann mit ein paar Dingen verbinden, ist dies selten ein Problem (aber manchmal schon);
- Fremdschlüssel sollten immer verwendet werden indiziert werden, es sei denn, Sie haben es mit einer trivial kleinen Tabelle zu tun;
Mehr in Fehler bei der Datenbankentwicklung von App-Entwicklern .
Was nun die Direktheit eines Modells betrifft, lassen Sie mich Ihnen ein Beispiel geben. Angenommen, Sie entwerfen ein System zur Authentifizierung und Autorisierung von Benutzern. Eine überarbeitete Lösung könnte etwa so aussehen:
- Alias (ID, Benutzername, Benutzer_ID);
- Benutzer (ID, ...);
- E-Mail (ID, Benutzer-ID, E-Mail-Adresse);
- Anmeldung (ID, Benutzer_ID, ...)
- Login-Rollen (id, login_id, role_id);
- Rolle (ID, Name);
- Rollenberechtigung (ID, Rollen_ID, Privileg_ID);
- Privileg (ID, Name).
Sie benötigen also 6 Joins, um vom eingegebenen Benutzernamen zu den tatsächlichen Berechtigungen zu gelangen. Sicher, es könnte eine tatsächliche Anforderung dafür geben, aber meistens wird diese Art von System eingeführt, weil einige Entwickler denken, dass sie es eines Tages brauchen könnten, obwohl jeder Benutzer nur einen Alias hat, Benutzer zum Anmelden ist 1 :1 und so weiter. Eine einfachere Lösung ist:
- Benutzer (ID, Benutzername, E-Mail-Adresse, Benutzertyp)
und, nun, das ist es. Vielleicht, wenn Sie ein komplexes Rollensystem benötigen, aber es ist auch durchaus möglich, dass Sie dies nicht tun, und wenn Sie dies tun, ist es relativ einfach einzufügen (der Benutzertyp wird zu einem Fremdschlüssel in einer Benutzertypen- oder Rollentabelle) oder es ist im Allgemeinen einfach, das abzubilden alt mach neu.
Hier geht es um Komplexität:Sie ist leicht hinzuzufügen und schwer zu entfernen. Normalerweise ist es eine ständige Wachsamkeit gegen unbeabsichtigte Komplexität, was schon schlimm genug ist, ohne es noch schlimmer zu machen, indem unnötige Komplexität hinzugefügt wird.
