Schlechte Praktiken im Datenbankdesign: Machen Sie diese Fehler?

Wann immer Sie als Entwickler eine Aufgabe auf der Grundlage von vorhandenem Code erhalten, müssen Sie sich vielen Herausforderungen stellen. Eine dieser Herausforderungen – meistens die anspruchsvollste – besteht darin, das Datenmodell einer Anwendung zu verstehen.

Normalerweise werden Sie mit verwirrenden Tabellen, Ansichten, Spalten, Werten, gespeicherten Prozeduren, Funktionen, Einschränkungen und Triggern konfrontiert, die erst nach langer Zeit einen Sinn ergeben. Und sobald sie dies tun, bemerken Sie viele Möglichkeiten, die gespeicherten Informationen zu verbessern und zu nutzen.

Wenn Sie ein erfahrener Entwickler sind, werden Ihnen wahrscheinlich auch Dinge auffallen, die am Anfang hätten besser gemacht werden können, z. B. Designfehler.

In diesem Artikel erfahren Sie mehr über einige der häufigsten schlechten Praktiken beim Datenbankdesign, warum sie schlecht sind und wie Sie sie vermeiden können.

Schlechte Praxis Nr. 1: Ignorieren des Zwecks der Daten

Daten werden gespeichert, um später verwendet zu werden, und das Ziel ist immer, sie so effizient wie möglich zu speichern und abzurufen. Um dies zu erreichen, muss der Datenbankdesigner im Voraus wissen, was die Daten darstellen werden, wie sie erfasst werden und mit welcher Geschwindigkeit, wie groß ihr Betriebsvolumen sein wird (dh wie viele Daten erwartet werden) und schließlich , wie es verwendet werden soll.

Beispielsweise hat ein industrielles Informationssystem, in dem Daten täglich manuell erfasst werden, nicht das gleiche Datenmodell wie ein industrielles System, in dem Informationen in Echtzeit generiert werden. Warum? Weil es ganz anders ist, einige hundert oder tausend Datensätze pro Monat zu verwalten, als Millionen von Datensätzen im gleichen Zeitraum zu verwalten. Spezielle Überlegungen müssen von den Designern angestellt werden, um die Leistungsfähigkeit und Benutzerfreundlichkeit der Datenbank zu erhalten, wenn die Datenmengen groß sein sollen.

Aber natürlich ist nicht nur das Datenvolumen zu berücksichtigen, da der Zweck der Daten auch den Normalisierungsgrad, die Datenstruktur, die Datensatzgröße und die allgemeine Implementierung des gesamten Systems beeinflusst.

Daher führt eine gründliche Kenntnis des Zwecks des zu erstellenden Datensystems zu Überlegungen bei der Auswahl der Datenbank-Engine, der zu entwerfenden Entitäten, der Datensatzgröße und des Formats sowie der Verwaltungsrichtlinien der Datenbank-Engine.

Das Ignorieren dieser Ziele führt zu Designs, die in ihren Grundlagen fehlerhaft sind, obwohl sie strukturell und mathematisch korrekt sind.

Schlechte Praxis Nr. 2: Schlechte Normalisierung

Das Entwerfen einer Datenbank ist keine deterministische Aufgabe; Zwei Datenbankdesigner können alle Regeln und Normalisierungsprinzipien für ein bestimmtes Problem befolgen, und in den meisten Fällen werden sie unterschiedliche Datenlayouts erzeugen. Dies liegt in der kreativen Natur des Software Engineerings. Es gibt jedoch einige Analysetechniken, die in jedem Fall sinnvoll sind, und ihre Befolgung ist der beste Weg, um zu einer Datenbank zu gelangen, die ihre beste Leistung erbringt.

Trotzdem sind wir oft mit Datenbanken konfrontiert, die spontan entworfen wurden, ohne die grundlegendsten Regeln der Normalisierung zu befolgen. Wir müssen uns darüber im Klaren sein: Jede Datenbank sollte zumindest auf die dritte Normalform normalisiert werden, da es das Layout ist, das Ihre Entitäten am besten darstellt und dessen Leistung am besten zwischen Abfragen und Einfügen-Aktualisieren-Löschen von Datensätzen ausbalanciert ist .

Wenn Sie auf Tabellen stoßen, die nicht 3NF, 2NF oder sogar 1NF entsprechen, sollten Sie eine Neugestaltung dieser Tabellen in Betracht ziehen. Der Aufwand, den Sie dabei investieren, zahlt sich schon nach kurzer Zeit aus.

Schlechte Praxis Nr. 3: Redundanz

Sehr verwandt mit dem vorherigen Punkt, da eines der Ziele der Normalisierung darin besteht, sie zu reduzieren, ist Redundanz eine weitere schlechte Praxis, die häufig auftritt.

Redundante Felder und Tabellen sind ein Albtraum für Entwickler, da sie eine Geschäftslogik erfordern, um viele Versionen derselben Informationen auf dem neuesten Stand zu halten. Dies ist ein Overhead, der vermieden werden kann, wenn die Normalisierungsregeln gründlich befolgt werden. Obwohl Redundanz manchmal notwendig erscheinen mag, darf sie nur in sehr speziellen Fällen verwendet und klar dokumentiert werden, um bei zukünftigen Entwicklungen berücksichtigt zu werden.

Typische negative Auswirkungen von Redundanz sind eine unnötige Zunahme der Datenbankgröße, Daten, die anfällig für Inkonsistenzen sind, und eine Verringerung der Effizienz der Datenbank, aber – was noch wichtiger ist – sie kann zu Datenbeschädigung führen.

Schlechte Praxis Nr. 4: Schlechte referentielle Integrität (Einschränkungen)

Die referenzielle Integrität ist eines der wertvollsten Werkzeuge, die Datenbank-Engines bieten, um die Datenqualität optimal zu halten. Wenn in der Entwurfsphase keine oder nur sehr wenige Einschränkungen implementiert werden, muss sich die Datenintegrität vollständig auf die Geschäftslogik verlassen, was sie anfällig für menschliche Fehler macht.

Schlechte Praxis Nr. 5: DB-Engine-Funktionen nicht nutzen

Wenn Sie eine Datenbank-Engine (DBE) verwenden, verfügen Sie über eine leistungsstarke Software für Ihre Datenverarbeitungsaufgaben, die die Softwareentwicklung vereinfacht und garantiert, dass Informationen immer korrekt, sicher und verwendbar sind. Eine DBE bietet Dienste wie:

• Ansichten, die eine schnelle und effiziente Möglichkeit bieten, Ihre Daten zu betrachten und sie in der Regel für Abfragezwecke zu denormalisieren, ohne die Korrektheit der Daten zu verlieren.
• Indizes, die helfen, Abfragen für Tabellen zu beschleunigen.
• Aggregatfunktionen, die helfen, Informationen ohne Programmierung zu analysieren.
• Transaktionen oder Blöcke von datenverändernden Sätzen, die alle ausgeführt und festgeschrieben oder abgebrochen (zurückgerollt) werden, wenn etwas Unerwartetes eintritt, wodurch die Informationen in einem dauerhaft korrekten Zustand gehalten werden.
• Sperren, die Daten sicher und korrekt halten, während Transaktionen ausgeführt werden.
• Gespeicherte Prozeduren, die Programmierfunktionen bereitstellen, um komplexe Datenverwaltungsaufgaben zu ermöglichen.
• Funktionen, die anspruchsvolle Berechnungen und Datentransformationen ermöglichen.
• Einschränkungen, die helfen, die Korrektheit der Daten zu gewährleisten und Fehler zu vermeiden.
• Trigger, die helfen, Aktionen zu automatisieren, wenn Ereignisse in den Daten auftreten.
• Befehlsoptimierer (Ausführungsplaner), der unter der Haube läuft und sicherstellt, dass jeder Satz optimal ausgeführt wird, und die Ausführungspläne für zukünftige Anlässe aufbewahrt. Dies ist einer der besten Gründe für die Verwendung von Ansichten, gespeicherten Prozeduren und Funktionen, da ihre Ausführungspläne dauerhaft in der DBE gespeichert werden.

Diese Fähigkeiten nicht zu kennen oder zu ignorieren, wird die Entwicklung auf einen äußerst ungewissen Weg bringen und sicher zu Fehlern und zukünftigen Problemen führen.

Schlechte Praxis Nr. 6: Zusammengesetzte Primärschlüssel

Dies ist ein kontroverser Punkt, da viele Datenbankdesigner heutzutage davon sprechen, ein automatisch generiertes Integer-ID-Feld als Primärschlüssel anstelle eines zusammengesetzten Felds zu verwenden, das durch die Kombination von zwei oder mehr Feldern definiert wird. Dies wird derzeit als „Best Practice“ definiert und ich persönlich stimme dem eher zu.

Dies ist jedoch nur eine Konvention, und natürlich erlauben DBEs die Definition von zusammengesetzten Primärschlüsseln, die viele Designer für unvermeidlich halten. Daher sind zusammengesetzte Primärschlüssel wie bei der Redundanz eine Entwurfsentscheidung.

Seien Sie jedoch vorsichtig, wenn Ihre Tabelle mit einem zusammengesetzten Primärschlüssel voraussichtlich Millionen von Zeilen enthalten wird, kann der Index, der den zusammengesetzten Schlüssel steuert, bis zu einem Punkt anwachsen, an dem die Leistung des CRUD-Vorgangs stark beeinträchtigt wird. In diesem Fall ist es viel besser, einen einfachen Integer-ID-Primärschlüssel zu verwenden, dessen Index kompakt genug ist und die notwendigen DBE-Einschränkungen einrichtet, um die Eindeutigkeit aufrechtzuerhalten.

Schlechte Praxis Nr. 7: Schlechte Indizierung

Manchmal haben Sie eine Tabelle, die Sie nach vielen Spalten abfragen müssen. Wenn die Tabelle wächst, werden Sie feststellen, dass die SELECTs für diese Spalten langsamer werden. Wenn die Tabelle groß genug ist, werden Sie logischerweise daran denken, einen Index für jede Spalte zu erstellen, die Sie für den Zugriff auf diese Tabelle verwenden, nur um fast sofort festzustellen, dass sich die Leistung von SELECTs verbessert, aber INSERTs, UPDATEs und DELETEs fallen. Dies liegt natürlich daran, dass Indizes mit der Tabelle synchron gehalten werden müssen, was einen massiven Overhead für die DBE bedeutet. Dies ist ein typischer Fall von Überindizierung, den Sie auf viele Arten lösen können. Wenn Sie beispielsweise nur einen Index für alle Spalten haben, die sich vom Primärschlüssel unterscheiden, den Sie zum Abfragen der Tabelle verwenden, bietet das Sortieren dieser Spalten von den am häufigsten verwendeten bis zu den am wenigsten verwendeten möglicherweise eine bessere Leistung bei allen CRUD-Vorgängen als ein Index pro Spalte.

Andererseits führt eine Tabelle ohne Index für Spalten, die zur Abfrage verwendet werden, wie wir alle wissen, zu einer schlechten Leistung bei SELECTs.

Außerdem hängt die Indexeffizienz manchmal vom Spaltentyp ab; Indizes auf INT-Spalten zeigen die bestmögliche Leistung, aber Indizes auf VARCHAR, DATE oder DECIMAL (falls es jemals Sinn macht) sind nicht so effizient. Diese Überlegung kann sogar dazu führen, dass Tabellen neu gestaltet werden, auf die mit der bestmöglichen Effizienz zugegriffen werden muss.

Daher ist die Indizierung immer eine heikle Entscheidung, da zu viel Indizierung ebenso schlecht wie zu wenig sein kann und weil der Datentyp der Spalten, auf die indiziert werden soll, einen großen Einfluss auf das Endergebnis hat.

Schlechte Praxis Nr. 8: Schlechte Namenskonventionen

Das ist etwas, womit Programmierer immer zu kämpfen haben, wenn sie mit einer bestehenden Datenbank konfrontiert sind: zu verstehen, welche Informationen darin durch die Namen von Tabellen und Spalten gespeichert sind, weil es oft keinen anderen Weg gibt.

Der Tabellenname muss beschreiben, welche Entität er enthält, und jeder Spaltenname muss beschreiben, welche Informationen er darstellt. Das ist einfach, wird aber kompliziert, wenn Tabellen zueinander in Beziehung gesetzt werden müssen. Namen beginnen unordentlich zu werden und, schlimmer noch, wenn es verwirrende Namenskonventionen mit unlogischen Normen gibt (wie zum Beispiel „Spaltenname muss 8 Zeichen oder weniger haben“). Die letzte Folge ist, dass die Datenbank unlesbar wird.

Daher ist eine Namenskonvention immer notwendig, wenn erwartet wird, dass die Datenbank Bestand hat und sich mit der von ihr unterstützten Anwendung weiterentwickelt, und hier sind einige Richtlinien, um eine prägnante, einfache und lesbare zu erstellen:

• Keine Beschränkungen für die Größe von Tabellen- oder Spaltennamen. Es ist besser, einen aussagekräftigen Namen zu haben als ein Akronym, an das sich niemand erinnert oder das niemand versteht.
• Gleiche Namen haben die gleiche Bedeutung. Vermeiden Sie Felder mit demselben Namen, aber unterschiedlichen Typen oder Bedeutungen; das wird früher oder später verwirrend sein.
• Seien Sie nicht überflüssig, es sei denn, es ist notwendig. Beispielsweise müssen in der Tabelle „Artikel“ keine Spalten wie „Artikelname“, „Artikelpreis“ oder ähnliche Namen vorhanden sein; „Name“ und „Preis“ genügen.
• Hüten Sie sich vor DBE-reservierten Wörtern. Wenn eine Spalte „Index“ genannt werden soll, was ein reserviertes SQL-Wort ist, versuchen Sie, ein anderes Wort wie „IndexNumber“ zu verwenden.
• Wenn Sie sich an die einfache Primärschlüsselregel halten (automatische Generierung einer einzelnen Ganzzahl), nennen Sie sie in jeder Tabelle „Id“.
• Definieren Sie beim Verknüpfen mit einer anderen Tabelle den erforderlichen Fremdschlüssel als Ganzzahl mit dem Namen „Id“, gefolgt vom Namen der verknüpften Tabelle (z. B. IdItem).
• Wenn Sie Einschränkungen benennen, verwenden Sie ein Präfix, das die Einschränkung beschreibt (z. B. „PK“ oder „FK“), gefolgt vom Namen der betreffenden Tabelle oder Tabellen. Natürlich hilft die sparsame Verwendung von Unterstrichen („_“), die Dinge besser lesbar zu machen.
• Um Indizes zu benennen, verwenden Sie das Präfix „IDX“, gefolgt vom Tabellennamen und der Spalte oder den Spalten des Indexes. Verwenden Sie außerdem „UNIQUE“ als Präfix oder Suffix, wenn der Index eindeutig ist, und gegebenenfalls Unterstriche.

Es gibt viele Benennungsrichtlinien für Datenbanken im Internet, die mehr Licht auf diesen sehr wichtigen Aspekt des Datenbankdesigns werfen, aber mit diesen grundlegenden Richtlinien können Sie zumindest zu einer lesbaren Datenbank gelangen. Wichtig ist hier nicht die Größe oder Komplexität Ihrer Namensrichtlinien, sondern Ihre konsequente Befolgung!

Einige Schlussbemerkungen

Datenbankdesign ist eine Kombination aus Wissen und Erfahrung; Die Softwareindustrie hat sich seit ihren Anfängen stark weiterentwickelt. Glücklicherweise ist genügend Wissen vorhanden, um Datenbankdesignern dabei zu helfen, die besten Ergebnisse zu erzielen.

Es gibt überall im Internet gute Richtlinien für das Datenbankdesign sowie schlechte Praktiken und Dinge, die beim Datenbankdesign vermieden werden sollten. Treffen Sie einfach Ihre Wahl und bleiben Sie dabei.

Und vergessen Sie nicht, dass Sie nur durch Experimentieren, Fehler und Erfolge lernen, also machen Sie weiter und beginnen Sie jetzt.