🥑 🏮 🙍 Eine bescheidene Anleitung zu Datenbankschemata 🚵🏾 🔃 👍🏼

Geometrie von Blumen von Mookiezoolook

Für Anwendungen, die sich nach Verkehr und Komplexität skalieren lassen, ist es äußerst wichtig, zunächst ein kompetentes Datenbankschema zu entwerfen. Wenn Sie eine schlechte Wahl treffen, müssen Sie viel Aufwand betreiben, damit sich diese schlechte Vorlage nicht auf Dienste und Backend-Controller und schließlich auf das Frontend ausbreitet.

Aber wie kann man beurteilen, welche Schaltung besser ist? Und was bedeutet "besser", wenn wir über Datenbankarchitektur sprechen? Das Mail.ru Cloud Solutions- Teamlädt Sie ein, den Empfehlungen von Mike Alcha , einem Berater für Softwareentwicklung,zu folgen . Es scheint uns, dass er einige Prinzipien kompetenter Architektur ziemlich kurz zusammengefasst hat.

Direktor: " Ich denke, wir sollten eine SQL-Datenbank erstellen . " Entwickler (versteht er überhaupt, wovon er spricht, oder hat er gerade eine Anzeige in einem Wirtschaftsmagazin gesehen? ..): „ Welche Farbe soll die Datenbank haben? ". Regie: " Vielleicht hat Flieder das meiste Gedächtnis . "

Ein paar grundlegende Tipps

Es ist also wichtig, zwei Hauptziele anzustreben :

Beim Aufteilen von Informationen in Tabellen werden alle Informationen gespeichert.
Die Redundanz des Speichers ist minimal.

Was den zweiten Punkt betrifft: Wollen wir die Redundanz nur aufgrund eines Problems mit der Speichergröße reduzieren? Nein, wir tun dies hauptsächlich, weil das Vorhandensein redundanter Daten zu Inkonsistenzproblemen führt, wenn Sie während der Aktualisierung nicht alle Felder aktualisieren, die dieselben Informationen darstellen.

Hier sind einige Richtlinien , um einer guten Architektur näher zu kommen :

Verwenden Sie mindestens die dritte normale Form (in der jedes Nicht-Schlüsselattribut "Informationen über den Schlüssel, den vollständigen Schlüssel und nichts als den Schlüssel liefern muss", gemäß dem Wortlaut von Bill Kent).
Erstellen Sie die letzte Verteidigungslinie in Form von Einschränkungen.
Speichern Sie niemals ganze Adressen in einem Feld.
Speichern Sie niemals den Vor- und Nachnamen in einem Feld.
Legen Sie Konventionen für Tabellen- und Feldnamen fest und halten Sie sich an diese.

- Woran arbeitest du?

" Optimieren dieser SQL-Abfrage." Es verlangsamt sich und Benutzer beginnen sich zu beschweren.

- Und obszöne Sprache in den Kommentaren ist für die Optimierung erforderlich ?

- Wenn Sie den Originalcode sehen würden, würden Sie nicht fragen.

Lassen Sie uns diese Empfehlungen genauer betrachten.

1. Verwenden Sie mindestens eine dritte Normalform

Die Datenbankarchitektur kann in folgende Kategorien unterteilt werden:

Die erste Normalform.
Die zweite Normalform.
Dritte Normalform.
Die normale Form von Boyce-Codd.

Diese Kategorien stellen eine Klassifizierung nach Qualität dar. Wir werden kurz alle Kategorien überprüfen und herausfinden, warum mindestens eine dritte Normalform benötigt wird.

Erste Normalform

Für die erste Normalform muss jeder Wert jeder Spalte jeder Tabelle in der Datenbank atomar sein. Was bedeutet Atom? Kurz gesagt, der Atomwert ist eine „einzelne Sache“.

Zum Beispiel haben wir eine Tabelle wie diese:

Vorname	Nachname	Alter	Bereiche
Jhon	Damhirschkuh	27	{"Website Design", "Clientele Research"}
Maria	Jane	33	{"Langfristige strategische Planung", "Rekrutierung"}
Tom	Schmied	35	{"Marketing"}

Hier enthält die Bereichsspalte Werte, die nicht atomar sind. In einer John Doe-Zeile speichert das Feld beispielsweise zwei Entitäten: Website-Design und Client-Recherche.

Diese Tabelle hat also nicht die erste normale Form.

Um es in dieses Formular zu bringen, sollte in jedem Feld nur ein Wert gespeichert werden .

Zweite Normalform

In der zweiten Normalform kann keine Spalte, die nicht Teil des Primärschlüssels ist (oder als Teil eines anderen Primärschlüssels fungieren kann), nicht aus dem kleineren Teil des Primärschlüssels abgeleitet werden .

Was bedeutet das?

Angenommen, Sie haben eine solche Basisarchitektur (ich habe die Felder hervorgehoben, die dem Primärschlüssel in dieser Tabelle entsprechen):

Mitarbeiter-ID	project_id	Std	Mitarbeitername	Projektname
1	1	10	John	"Website design"
2	1	zwanzig	Maria	"Website design"

In diesem Projekt kann der Name des Mitarbeiters direkt aus employeee_id abgeleitet werden, da der Name des Mitarbeiters eindeutig durch seine Kennung bestimmt wird.

In ähnlicher Weise wird der Projektname durch die Kennung project_id eindeutig identifiziert.

Wir haben also zwei Spalten, die aus dem Primärschlüsselteil abgeleitet werden können.

Jedes dieser Beispiele würde ausreichen, um diese Tabelle aus der zweiten Normalform herauszuwerfen.

Eine andere Schlussfolgerung ist, dass wenn die Tabelle in der ersten Normalform war und alle Primärschlüssel einzelne Spalten sind, die Tabelle bereits in der zweiten Normalform ist.

Dritte Normalform

Damit die Tabelle der dritten Normalform entspricht, muss sie in der zweiten Normalform vorliegen, während sie keine Attribute (Spalten) enthalten sollte, außer der primären, die transitiv vom Primärschlüssel abhängig sind.

Was bedeutet das?

Angenommen, Sie haben die folgende Architektur (die alles andere als ideal ist):

Mitarbeitername	Mitarbeiter-ID	Alter	Abteilungsnummer	Abteilungsname
John	1	27	123	"Marketing"
Maria	2	33	456	"Operational"
Tom	3	35	123	"Marketing"

In dieser Tabelle kann die Abteilungsnummer aus der Mitarbeiter-ID und der Abteilungsname aus der Abteilungsnummer abgeleitet werden. Abteilungsname ist also transitiv von employee_id abhängig!

Wenn es eine solche transitive Abhängigkeit gibt: Mitarbeiter-ID → Abteilungsnummer → Abteilungsname, dann hat diese Tabelle nicht die dritte normale Form.

Welche Probleme entstehen dadurch ?

Wenn der Name der Abteilung aus ihrer Nummer abgeleitet werden kann, führt das Speichern dieses Felds für jeden Mitarbeiter zu einer übermäßigen Redundanz.

Stellen Sie sich vor, die Marketingabteilung ändert ihren Namen in "Marketing und Vertrieb". Um die Konsistenz zu gewährleisten, müssen Sie die Zelle in jeder Zeile der Tabelle für jeden Mitarbeiter in dieser Abteilung aktualisieren! In der dritten Normalform wäre dies nicht geschehen.

Darüber hinaus geschieht Folgendes, wenn Mary beschließt, das Unternehmen zu verlassen: Wir müssen ihre Zeile aus der Tabelle löschen. Wenn sie jedoch die einzige Mitarbeiterin in der Betriebsabteilung war, muss die Abteilung ebenfalls gelöscht werden.

All diese Probleme können in einer dritten Normalform vollständig vermieden werden.

Mamas Heldentaten . Der Name ihrer Tochter ist Hilfe! Ich bin gezwungen, Pässe zu fälschen

2. Erstellen Sie die letzte Verteidigungslinie in Form von Einschränkungen

Die Datenbank, mit der Sie arbeiten, ist mehr als nur eine Gruppe von Tabellen. Bestimmte Funktionen sind darin integriert. Viele dieser Funktionen tragen zur Gewährleistung der Datenqualität und -genauigkeit bei.

Einschränkungen legen die Regeln fest, welche Werte in die Datenbankfelder eingegeben werden können.

Stellen Sie beim Definieren von Beziehungen in einer Datenbank sicher, dass Sie Fremdschlüsseleinschränkungen festlegen.

Stellen Sie sicher, dass Sie angeben, was beim Löschen und Aktualisieren einer Zeile geschehen soll, die anderen Zeilen in anderen Tabellen zugeordnet ist (ON DELETE- und ON UPDATE-Regeln).

Stellen Sie sicher, dass Sie NOT NULL für alle Felder verwenden, die niemals annulliert werden sollten. Es mag sinnvoll sein, das Backend zu überprüfen, aber denken Sie daran, dass es immer zu Abstürzen kommt, sodass das Hinzufügen dieser Art von Einschränkung nicht schadet.

Legen Sie die CHECK-Prüfgrenzen fest, um sicherzustellen, dass die Tabellenwerte im akzeptablen Bereich liegen. Beispielsweise hat der Preis eines Produkts immer einen positiven Wert.

Eine interessante Tatsache : Im April 2020 verhinderte genau eine solche Einschränkung der Software den Handel an der Moskauer MICEX, da der Preis für WTI-Öl-Futures unter Null fiel. Im Gegensatz zur Moskauer Börse hat die New York Mercantile Exchange NYMEX die Software eine Woche vor dem Vorfall aktualisiert , sodass Transaktionen zu einem negativen Preis erfolgreich durchgeführt werden konnten, dh mit einem Zuschlag des Verkäufers an den Käufer - ca. trans.

Alle PostgreSQL-Einschränkungen finden Sie hier .

3. Speichern Sie niemals ganze Adressen in einem Feld

Wenn Ihre Anwendung oder Website ein Formular mit einem Feld enthält, in das der Benutzer seine Adresse eingibt, riecht es schlecht. Es ist sehr wahrscheinlich, dass Sie in diesem Fall auch ein Feld in der Datenbank haben, um die Adresse als einfache Zeichenfolge zu speichern.

Aber was tun, wenn Sie Kundeneinkäufe nach Städten kombinieren müssen, um festzustellen, in welcher Stadt welches Produkt beliebter ist? Kannst du es machen?

Es wird sehr schwer sein!

Da die vollständige Adresse als Zeichenfolge im Datenbankfeld gespeichert ist, müssen Sie zuerst herausfinden, wie viel von dieser Zeichenfolge die Stadt ist! Und dies ist angesichts aller möglichen Adressformate in diesem Bereich eine fast unmögliche Aufgabe.

Teilen Sie daher das universelle Feld "Adresse" in bestimmte Felder auf: Straße, Hausnummer, Stadt, Region, Postleitzahl usw.

Ein weiteres Adressproblem - Anonyme Felder

Hier ist eine Illustration aus Michaels Blachs Buch The Copper Bullet zur Verbesserung der Softwarequalität:

Welche potenziellen Probleme sind hier sichtbar? Können Sie die Stadt Chicago leicht von den Straßen von Chicago unterscheiden? Wahrscheinlich nicht.

Denken Sie daher daran, jeder Informationseinheit immer eindeutige Spaltennamen zuzuweisen.

Wie schreibe ich einen Lebenslauf

- Haben Sie Erfahrung in SQL?

- Nein (Nein).

- Schreiben Sie also: NoSQL-Experte.

4. Speichern Sie niemals den Vor- und Nachnamen in einem Feld

Ähnlich wie bei Adressen: Die Anzahl der Variationen von Vor- und Nachnamen ist zu groß, um klar zwischen ihnen zu unterscheiden.

Natürlich können Sie den Namen vom Nachnamen trennen, wenn zwischen ihnen ein Leerzeichen steht.

Zum Beispiel "Mike Alche" → der Name "Mike" und der Nachname "Alche".

Was aber, wenn der Benutzer einen zweiten Vornamen eingegeben hat? Oder hat er einen doppelten Nachnamen? Aber was ist, wenn es einen zweiten Vornamen und einen doppelten Nachnamen gibt?

Wie kann man feststellen, wo der Name und wo der Nachname ist, um die Zeichenfolge zu teilen? Fehler sind unvermeidlich.

Eine Möglichkeit, viele Probleme zu vermeiden, besteht darin, separate Felder (in Formularen) für die Benutzernamen Vorname und Nachname zu erstellen. Auf diese Weise ermöglichen Sie Benutzern, ihre eigenen Namen zu teilen und Daten auf konsistente Weise zu speichern.

Hinweis: Ich sage nicht, dass Leerzeichen in den Feldern der Datenbank verboten sind. Bei Namen wie Juan Martin Del Potro befindet sich beispielsweise der erste Teil von Juan Martin im Feld Vorname und Del Potro im Feld Nachname. Das ist natürlich nicht perfekt . Optional können Sie die Spalten mid_name und second_last_name haben. Weitere Informationen zu möglichen Variationen von Vor- und Nachnamen finden Sie in der Liste „ Missverständnisse von Programmierern über Namen “ und im Artikel „ Missverständnisse von Programmierern über Namen - mit Beispielen “. Sie müssen sich auf einen Kompromiss zwischen Genauigkeit und Praktikabilität einigen.

5. Legen Sie Konventionen für Tabellen- und Feldnamen fest und halten Sie sich an diese

Es ist ziemlich ärgerlich, mit Daten zu arbeiten, die wie user.firstName, user.lst_name, user.birthDate usw. aussehen.

Ich würde Ihnen raten, Regeln für die Benennung von Unterstrichen festzulegen, da nicht alle SQL-Engines Großbuchstaben gleich behandeln und es sehr mühsam ist, alles in Anführungszeichen zu setzen.

Wählen Sie dasselbe wie das Aufrufen der Tabellen - im Plural oder Singular (z. B. Benutzer im Plural oder Benutzer im Singular). Ich mag den Singular mehr, aber alle Backend-Frameworks scheinen standardmäßig plural zu sein. Sie müssen dem Muster folgen und den Plural verwenden.

Was noch zu lesen :

Eine bescheidene Anleitung zu Datenbankschemata