Unabhängig davon, ob Sie mit einer Datenbank arbeiten, die Hunderte von Datensätzen oder Millionen von Datensätzen enthält, ist das richtige Datenbankdesign immer wichtig. Dies erleichtert nicht nur das Abrufen der Informationen, sondern vereinfacht auch das Erweitern der Datenbank in der Zukunft. Leider fällt es leicht, in ein paar Fallen zu geraten, die in Zukunft Schwierigkeiten bereiten können.
Es gibt ganze Bücher zum Thema Normalisierung einer Datenbank, aber wenn Sie einfach die hier gezeigten Fehler vermeiden, sind Sie auf dem richtigen Weg zum guten Datenbankdesign.
Datenbankfehler # 1: Wiederholen von Feldern in einer Tabelle
Eine grundlegende Faustregel für ein gutes Datenbankdesign besteht darin, sich wiederholende Daten zu erkennen und diese sich wiederholenden Spalten in eine eigene Tabelle zu stellen. Das Wiederholen von Feldern in einer Tabelle ist für alle, die aus der Welt der Tabellenkalkulationen stammen, üblich. Obwohl Tabellenkalkulationen zwar eher flach sind, sollten Datenbanken jedoch relational sein. Es ist wie von 2D zu 3D zu wechseln.
Glücklicherweise sind sich wiederholende Felder normalerweise leicht zu erkennen. Schauen Sie sich einfach diese Tabelle an:
| Auftragsnummer | Produkt1 | Produkt2 | Produkt3 |
| 1 | Teddybären | Jelly Beans | |
| 2 | Jelly Beans |
Was passiert, wenn eine Bestellung vier Produkte enthält? Wir müssen der Tabelle ein weiteres Feld hinzufügen, um mehr als drei Produkte zu unterstützen. Wenn wir eine Clientanwendung rund um die Tabelle erstellt haben, um die Dateneingabe zu erleichtern, müssen wir sie möglicherweise mit dem neuen Produktfeld ändern. Und wie finden wir alle Bestellungen mit Jellybeans in der Bestellung? Wir wären gezwungen, jedes Produktfeld in der Tabelle mit einer SQL-Anweisung abzufragen, die wie folgt aussehen könnte: SELECT * FROM Products WHERE Product1 = 'Jelly Beans' ODER Product2 = 'Jelly Beans' ODER Product3 = 'Jelly Beans'.
Anstatt eine einzige Tabelle zu haben, die alle Informationen zusammenfügt, sollten wir drei Tabellen haben, die jeweils eine bestimmte Information enthalten. In diesem Beispiel möchten wir eine Bestelltabelle mit Informationen zur Bestellung selbst, eine Produkttabelle mit allen unseren Produkten und eine ProductOrders-Tablette, die die Produkte mit der Bestellung verknüpft.
| Auftragsnummer | Kundennummer | Auftragsdatum | Gesamt |
| 1 | 7 | 1/24/17 | 19.99 |
| 2 | 9 | 1/25/17 | 24.99 |
| Produkt ID | Produkt | Anzahl |
| 1 | Teddybären | 1 |
| 2 | Jelly Beans | 100 |
| ProductOrderID | Produkt ID | Auftragsnummer |
| 101 | 1 | 1 |
| 102 | 2 | 1 |
Beachten Sie, dass jede Tabelle ein eigenes eindeutiges ID-Feld hat. Dies ist der Primärschlüssel. Wir verknüpfen Tabellen, indem wir einen Primärschlüsselwert als Fremdschlüssel in einer anderen Tabelle verwenden. Lesen Sie mehr über Primärschlüssel und Fremdschlüssel.
Datenbankfehler # 2: Einbetten einer Tabelle in eine Tabelle
Dies ist ein weiterer häufiger Fehler, der jedoch nicht immer so hervorsticht wie sich wiederholende Felder. Wenn Sie eine Datenbank entwerfen, möchten Sie sicherstellen, dass sich alle Daten in einer Tabelle auf sich selbst beziehen. Es ist wie das Spiel dieses Kindes über das Erkennen von Unterschieden. Wenn Sie eine Banane, eine Erdbeere, einen Pfirsich und ein Fernsehgerät haben, gehört das Fernsehgerät wahrscheinlich woanders hin.
Wenn Sie über eine Tabelle von Vertriebsmitarbeitern verfügen, sollten sich alle Informationen in dieser Tabelle speziell auf diesen Vertriebsmitarbeiter beziehen. Zusätzliche Informationen, die nicht für diesen Vertriebsmitarbeiter eindeutig sind, können an anderer Stelle in Ihrer Datenbank enthalten sein.
| SalesID | Zuerst | Zuletzt | Adresse | Telefonnummer | Büro | Büro nummer |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | Austin Downtown | (212) 421-2412 |
| 2 | Alice | Schmied | 504 2nd Street, New York, NY | (211) 122-1821 | New York (Osten) | (211) 855-4541 |
| 3 | Joe | Gemeinde | 428 Aker Street, Austin, TX | (215) 545-5545 | Austin Downtown | (212) 421-2412 |
Während diese Tabelle möglicherweise so aussieht, als ob sie sich auf den einzelnen Verkäufer bezieht, hat sie tatsächlich eine in die Tabelle eingebettete Tabelle. Beachten Sie, wie sich Office und OfficeNumber mit "Austin Downtown" wiederholen. Was ist, wenn sich eine Bürotelefonnummer ändert? Sie müssten eine ganze Reihe von Daten für eine einzelne veränderte Information aktualisieren, was nie gut ist. Diese Felder sollten in eine eigene Tabelle verschoben werden.
| SalesID | Zuerst | Zuletzt | Adresse | Telefonnummer | OfficeID |
| 1 | Sam | Elliot | 118 Main St, Austin, TX | (215) 555-5858 | 1 |
| 2 | Alice | Schmied | 504 2nd Street, New York, NY | (211) 122-1821 | 2 |
| 3 | Joe | Gemeinde | 428 Aker Street, Austin, TX | (215) 545-5545 | 1 |
| OfficeID | Büro | Büro nummer |
| 1 | Austin Downtown | (212) 421-2412 |
| 2 | New York (Osten) | (211) 855-4541 |
Diese Art von Design gibt Ihnen außerdem die Möglichkeit, zusätzliche Informationen zum Office-Tisch hinzuzufügen, ohne einen Albtraum von Unordnung in der Verkaufspersonaltabelle zu erzeugen. Stellen Sie sich vor, wie viel Arbeit es wäre, einfach die Straße, den Ort, den Bundesstaat und die Postleitzahl zu verfolgen, wenn sich all diese Informationen in der Tabelle der Verkäufer befinden würden!
Datenbankfehler Nr. 3: Zwei oder mehr Informationen in ein einzelnes Feld einfügen
Das Einbetten der Büroinformationen in die Verkäufer-Tabelle war nicht das einzige Problem mit dieser Datenbank. Das Adressfeld enthielt drei Informationen: die Straße, die Stadt und den Staat. Jedes Feld in der Datenbank sollte nur eine einzige Information enthalten. Wenn Sie mehrere Informationen in einem einzigen Feld haben, kann es schwieriger werden, die Datenbank nach Informationen abzufragen.
Was wäre zum Beispiel, wenn wir eine Abfrage für alle Vertriebsmitarbeiter aus Austin ausführen wollten? Wir müssten innerhalb des Adressfelds suchen, was nicht nur ineffizient ist, sondern auch schlechte Informationen zurückgeben kann. Was passiert, wenn jemand in der Austin-Straße in Portland, Oregon, lebt?
So sollte der Tisch aussehen:
| SalesID | Zuerst | Zuletzt | Adresse 1 | Adresse 2 | Stadt | Zustand | Postleitzahl | Telefon |
| 1 | Sam | Elliot | 118 Hauptstraße | Austin | TX | 78720 | 2155555858 | |
| 2 | Alice | Schmied | 504 2nd St | New York | NY | 10022 | 2111221821 | |
| 3 | Joe | Gemeinde | 428 Aker St | Apt 304 | Austin | TX | 78716 | 2155455545 |
Hier gibt es ein paar Dinge zu beachten.Erstens scheinen "Address1" und "Address2" unter dem Fehler der sich wiederholenden Felder zu liegen.
In diesem Fall beziehen sie sich jedoch auf separate Daten, die sich direkt auf den Verkäufer beziehen, und nicht auf eine sich wiederholende Gruppe von Daten, die in eine eigene Tabelle aufgenommen werden sollten.
Beachten Sie als Bonusfehler auch, wie die Formatierung für die Telefonnummer aus der Tabelle entfernt wurde. Sie sollten das Format von Feldern möglichst nicht speichern. Bei Telefonnummern gibt es mehrere Möglichkeiten, wie man eine Telefonnummer schreibt: 215-555-5858 oder (215) 555-5858. Dies würde die Suche nach einem Verkäufer nach seiner Telefonnummer oder die Suche nach Verkäufern in derselben Vorwahl schwieriger machen.
Datenbankfehler # 4: Verwenden eines korrekten Primärschlüssels nicht
In den meisten Fällen möchten Sie eine automatisch inkrementierende Nummer oder eine andere generierte oder alphanumerische Nummer für Ihren Primärschlüssel verwenden. Sie sollten es vermeiden, tatsächliche Informationen für den Primärschlüssel zu verwenden, auch wenn dies so aussieht, als wäre dies eine gute Kennung.
Wir haben zum Beispiel jeweils eine eigene Sozialversicherungsnummer, daher mag es eine gute Idee sein, die Sozialversicherungsnummer für eine Mitarbeiterdatenbank zu verwenden. In seltenen Fällen kann sich sogar eine Sozialversicherungsnummer ändern, und wir möchten niemals, dass sich unser Primärschlüssel ändert.
Und das ist das Problem, wenn tatsächliche Informationen als Schlüsselwert verwendet werden. Es kann sich ändern.
Datenbankfehler 5: Keine Namenskonvention verwenden
Das hört sich vielleicht nicht nach einer großen Sache an, wenn Sie zum ersten Mal mit dem Entwurf Ihrer Datenbank beginnen. Sobald Sie jedoch Abfragen gegen die Datenbank geschrieben haben, um Informationen abzurufen, hilft eine Namenskonvention, wenn Sie sich Feldnamen merken.
Stellen Sie sich vor, wie viel schwieriger dieser Prozess wäre, wenn Namen als Vorname, Nachname in einer Tabelle und Vorname_Name, Nachname in einer anderen Tabelle gespeichert würden.
Die zwei bekanntesten Namenskonventionen setzen den ersten Buchstaben jedes Wortes im Feld in Großbuchstaben oder trennen die Wörter mit einem Unterstrich. Möglicherweise sehen Sie auch einige Entwickler, die den ersten Buchstaben jedes Wortes mit Ausnahme des ersten Wortes groß schreiben: firstName, lastName.
Sie möchten auch einzelne Tabellennamen oder mehrere Tabellennamen verwenden. Ist es eine Auftragstabelle oder eine Auftragstabelle? Handelt es sich um einen Kundentisch oder einen Kundentisch? Wieder möchten Sie nicht mit einer Auftragstabelle und einer Kundentabelle hängen bleiben.
Die von Ihnen gewählte Namenskonvention ist nicht so wichtig wie der Prozess, bei dem Sie eine Namenskonvention tatsächlich auswählen und einhalten.
Datenbankfehler # 6: Unsachgemäße Indizierung
Indizierung ist eines der am schwierigsten zu machenden Dinge, vor allem für diejenigen, die neu beim Datenbankdesign sind. Alle Primärschlüssel und Fremdschlüssel sollten indiziert werden. Dies ist, was Tabellen miteinander verknüpft. Ohne einen Index wird die Leistung Ihrer Datenbank daher sehr schlecht.
Was jedoch zu oft übersehen wird, sind die anderen Bereiche. Dies sind die "WHERE" -Felder. Wenn Sie Ihre Suche häufig mithilfe eines Feldes in einer WHERE-Klausel eingrenzen, möchten Sie darüber nachdenken, ob dieses Feld mit einem Index versehen werden soll. Sie möchten die Tabelle jedoch nicht übermäßig indizieren, was die Leistung beeinträchtigen kann.
Wie soll ich entscheiden? Dies ist Teil der Kunst des Datenbankdesigns. Es gibt keine festen Grenzen für die Anzahl der Indizes, die Sie auf eine Tabelle setzen sollten. In erster Linie möchten Sie jedes Feld indizieren, das häufig in einer WHERE-Klausel verwendet wird. Lesen Sie mehr über die korrekte Indizierung Ihrer Datenbank.
