Best Practice für das Datenbankdesign für leistungsstarke Apps

Für eine gute Leistung einer Anwendung benötigen Sie einen leistungsstarken Anwendungsserver, eine garantierte und ausreichende Bandbreite und eine gut ausgeführte Programmierarbeit. Es gibt jedoch einen Aspekt, der nicht immer berücksichtigt wird und in der Regel einen großen Einfluss auf die Performance jeder Anwendung hat: die Datenbank Design.

Wir werden uns nun die Best Practices für das Datenbankdesign ansehen, um sicherzustellen, dass der Datenzugriff kein Engpass ist, der sich negativ auf die Anwendungsleistung auswirkt.

Was ist der Zweck eines guten Datenbankdesigns?

Neben der Verbesserung der Datenzugriffsleistung bietet ein gutes Design weitere Vorteile, wie z. Ein weiterer Vorteil eines guten Designs besteht darin, dass die Datenbank einfacher zu verwenden und zu warten ist. Jeder, der es verwalten muss, muss sich nur das Entity-Relationship-Diagramm (ERD) ansehen, um seine Struktur zu verstehen.

ERDs sind das grundlegende Werkzeug des Datenbankdesigns. Sie können auf drei Gestaltungsebenen erstellt und visualisiert werden: begrifflich, logisch und physikalisch.

Das konzeptionelle Design zeigt ein sehr zusammengefasstes Diagramm mit nur den Elementen, die erforderlich sind, um mit den Projektbeteiligten Kriterien zu vereinbaren, die die technischen Details der Datenbank nicht verstehen müssen. Das logische Design zeigt die Entitäten und ihre Beziehungen im Detail, aber datenbankunabhängig.

Es gibt viele Tools, die Sie verwenden können, um den Entwurf von Datenbanken aus ERDs zu erleichtern. Zu den besten gehören dbSchema, SqlDBM und Vertabelo.

DbSchema

dbSchema ermöglicht Ihnen die visuelle Gestaltung und Verwaltung von SQL, NoSQL, oder Cloud-Datenbanken. Mit dem Tool können Sie unter anderem das Schema auf einem Computer entwerfen und in mehreren Datenbanken bereitstellen und Dokumentation in HTML5-Diagrammen erstellen, Abfragen schreiben und die Daten visuell untersuchen. Es bietet auch Schemasynchronisierung, zufällige Datengenerierung und SQL-Code-Bearbeitung mit automatischer Vervollständigung.

SqlDBM

SqlDBM ist eines der besten Tools zum Erstellen von Datenbankdiagrammen, da es eine einfache Möglichkeit bietet, Ihre Datenbank in jedem Browser zu entwerfen. Es sind keine anderen Datenbank-Engines oder Modellierungstools erforderlich, um es zu verwenden, obwohl Sie mit SqlDBM ein Schema aus einer vorhandenen Datenbank importieren können. Es ist ideal für , da Sie damit Designprojekte mit Kollegen teilen können.

Vertabelo

Vertabelo ist ein Online-Tool zum visuellen Datenbankdesign, mit dem Sie eine Datenbank logisch entwerfen und das physische Schema automatisch ableiten können. Es kann Reverse Engineering durchführen, Diagramme aus vorhandenen Datenbanken generieren und den Zugriff auf die Diagramme steuern, indem es Zugriffsberechtigungen für Besitzer, Redakteure und Betrachter differenziert.

Schließlich ist das physische Design dasjenige, das dem ERD alle notwendigen Details hinzufügt, um es in eine verwendbare Datenbank in einem bestimmten DBMS zu verwandeln, wie z MySQL, MariaDB, MS SQL Server oder andere. Sehen wir uns die Best Practices an, die Sie beim Entwerfen einer ERD berücksichtigen sollten, damit die resultierende Datenbank optimal funktioniert.

Define the type of database to design

Üblicherweise werden zwei grundlegende Arten von Datenbanken unterschieden: relational funktioniert dimensional.

Relationale Datenbanken werden für traditionelle Anwendungen verwendet, die Transaktionen mit den Daten ausführen, dh Informationen aus der Datenbank abrufen, verarbeiten und die Ergebnisse speichern.

Auf der anderen Seite werden Dimensionsdatenbanken für die Erstellung von Data Warehouses verwendet: große Informationsquellen für die Datenanalyse und das Data Mining, um Erkenntnisse zu gewinnen.

Der erste Schritt bei jeder Datenbankentwurfsaufgabe besteht darin, einen der beiden Hauptdatenbanktypen auszuwählen, mit denen gearbeitet werden soll: relational oder dimensional. Es ist wichtig, dies zu klären, bevor Sie mit der Gestaltung beginnen. Andernfalls können Sie leicht in Konstruktionsfehler verfallen, die schließlich zu vielen Problemen führen und schwer (oder unmöglich) zu korrigieren sind.

Adopting a Naming Convention

Die beim Datenbankentwurf verwendeten Namen sind wichtig, da die Namensänderung nach der Erstellung eines Objekts in einer Datenbank fatale Folgen haben kann. Wenn Sie nur einen Buchstaben des Namens ändern, können Abhängigkeiten, Beziehungen und sogar ganze Systeme zerstört werden.

Aus diesem Grund ist es wichtig, mit einer gesunden Namenskonvention zu arbeiten: einem Regelwerk, das Ihnen das Ausprobieren von 50 verschiedenen Möglichkeiten erspart, den Namen eines Objekts zu finden, an das Sie sich nicht erinnern können.

Es gibt keinen universellen Leitfaden dafür, was eine Namenskonvention sein sollte, um ihre Aufgabe zu erfüllen. Wichtig ist jedoch, dass Sie eine Namenskonvention festlegen, bevor Sie eines der Objekte in einer Datenbank benennen und diese Konvention für immer beibehalten. Eine Namenskonvention legt Richtlinien fest, z. B. ob ein Unterstrich verwendet werden soll, um Wörter zu trennen oder direkt zu verbinden, ob alle Großbuchstaben verwendet oder Wörter groß geschrieben werden (Camel Case-Stil), ob Plural- oder Singularwörter zum Benennen von Objekten verwendet werden und so weiter.

Beginnen Sie mit dem konzeptionellen Design, dann dem logischen Design und schließlich dem physischen Design.

Das ist die natürliche Ordnung der Dinge. Als Designer könnten Sie versucht sein, zunächst Objekte direkt auf dem DBMS zu erstellen, um Schritte zu überspringen. Dies verhindert jedoch, dass Sie über ein Tool verfügen, mit dem Sie mit den Beteiligten diskutieren können, um sicherzustellen, dass das Design den Geschäftsanforderungen entspricht.

Nach dem konzeptionellen Entwurf müssen Sie zum logischen Entwurf übergehen, um eine angemessene Dokumentation zu haben, die den Programmierern hilft, die Datenbankstruktur zu verstehen. Es ist wichtig, das logische Design auf dem neuesten Stand zu halten, um unabhängig von der zu verwendenden Datenbank-Engine zu sein. Auf diese Weise ist das logische Design auch dann nützlich, wenn Sie die Datenbank schließlich auf eine andere Engine migrieren.

Schließlich kann das physische Design von den Programmierern selbst oder von einem DBA erstellt werden, wobei das logische Design genommen und alle Implementierungsdetails hinzugefügt werden, die für die Implementierung in einem bestimmten DBMS erforderlich sind.

Create and maintain a data dictionary

Auch wenn ein ERD klar und beschreibend ist, sollten Sie ein Datenwörterbuch hinzufügen, um es noch klarer zu machen. Das Datenwörterbuch bewahrt Kohärenz und Konsistenz im Datenbankdesign, insbesondere wenn die Anzahl der darin enthaltenen Objekte erheblich anwächst.

Der Hauptzweck des Datenwörterbuchs besteht darin, ein einzelnes Repository mit Referenzinformationen über die Entitäten eines Datenmodells und seine Attribute zu verwalten. Das Datenwörterbuch sollte die Namen aller Entitäten, die Namen aller Attribute, deren Formate und Datentypen sowie eine kurze Beschreibung enthalten.

Das Datenwörterbuch bietet eine klare und prägnante Anleitung zu allen Elementen, aus denen die Datenbank besteht. Dadurch wird vermieden, dass mehrere Objekte erstellt werden, die dasselbe darstellen, was es schwierig macht, zu wissen, auf welches Objekt Sie zurückgreifen müssen, wenn Sie Informationen abfragen oder aktualisieren müssen.

Maintain consistent criteria for primary keys

Die Entscheidung, natürliche Schlüssel oder Ersatzschlüssel zu verwenden, muss innerhalb eines Datenmodells konsistent sein. Wenn Entitäten in einem Datenmodell eindeutige Bezeichner haben, die effizient als Primärschlüssel ihrer jeweiligen Tabellen verwaltet werden können, müssen keine Ersatzschlüssel erstellt werden.

Es ist jedoch üblich, dass Entitäten durch mehrere Attribute unterschiedlicher Typen identifiziert werden – Datumsangaben, Zahlen und/oder lange Zeichenfolgen –, was für die Bildung von Primärschlüsseln ineffizient sein kann. In diesen Fällen ist es besser, Ersatzschlüssel des ganzzahligen numerischen Typs zu erstellen, die maximale Effizienz bei der Indexverwaltung bieten. Und der Ersatzschlüssel ist die einzige Option, wenn einer Entität Attribute fehlen, die sie eindeutig identifizieren.

Use the correct data types for each attribute.

Bestimmte Daten geben uns die Möglichkeit, auszuwählen, welcher Datentyp zu ihrer Darstellung verwendet werden soll. Termine zum Beispiel. Wir können sie in Datumstypfeldern, Datums-/Uhrzeittypfeldern, Varchar-Typfeldern oder sogar numerischen Typfeldern speichern. Ein anderer Fall sind numerische Daten, die nicht für mathematische Operationen verwendet werden, sondern um eine Entität zu identifizieren, beispielsweise eine Führerscheinnummer oder eine Postleitzahl.

Bei Datumsangaben ist es zweckmäßig, den Datentyp der Engine zu verwenden, was die Bearbeitung von Daten erleichtert. Wenn Sie nur das Datum eines Ereignisses ohne Angabe der Uhrzeit speichern müssen, ist der zu wählende Datentyp einfach Datum; Wenn Sie Datum und Uhrzeit des Auftretens eines bestimmten Ereignisses speichern müssen, sollte der Datentyp DateTime sein.

Die Verwendung anderer Typen wie varchar oder numerisch zum Speichern von Daten kann praktisch sein, aber nur in ganz besonderen Fällen. Wenn beispielsweise im Voraus nicht bekannt ist, in welchem ​​Format ein Datum ausgedrückt wird, ist es praktisch, es als varchar zu speichern. Wenn Suchleistung, Sortierung oder Indexierung bei der Verarbeitung von Datumsfeldern entscheidend sind, kann eine vorherige Konvertierung in Float einen Unterschied machen.

Numerische Daten, die nicht an mathematischen Operationen beteiligt sind, sollten als varchar dargestellt werden, wobei Formatvalidierungen in der Aufzeichnung angewendet werden, um Inkonsistenzen oder Wiederholungen zu vermeiden. Andernfalls setzen Sie sich dem Risiko aus, dass einige Daten die Beschränkungen der numerischen Felder überschreiten und Sie zwingen, einen Entwurf umzugestalten, wenn dieser bereits in Produktion ist.

Use of lookup tables

Einige unerfahrene Designer glauben vielleicht, dass die übermäßige Verwendung von Lookup-Tabellen zur Normalisierung eines Designs die ERD einer Datenbank unnötig komplizieren kann, da eine große Anzahl von „Satelliten“-Tabellen hinzugefügt wird, die manchmal nicht mehr als eine Handvoll Elemente enthalten. Diejenigen, die dies denken, sollten verstehen, dass die Verwendung von Nachschlagetabellen viel mehr Vorteile als Nachteile hat. Wenn die Komplexität oder Größe eines ERD ein Problem darstellt, gibt es ERD-Designtools, die es Ihnen ermöglichen, die Diagramme trotz ihrer Komplexität auf verschiedene Weise zu visualisieren, um sie zu verstehen.

Diese Beispielabfrage veranschaulicht die korrekte Verwendung von Nachschlagetabellen in einer gut gestalteten Datenbank:

SELECT
	StreetName,
	StreetNumber,
	Cities.Name AS City,
	States.Name AS State
FROM
	Addresses
	INNER JOIN Cities ON
		Cities.CityId = Addresses.CityId
	INNER JOIN States ON
		States.StateId = Addresses.StateId

In diesem Fall verwenden wir Nachschlagetabellen für Städte und Staaten.

Zu den Vorteilen von Nachschlagetabellen gehören die Reduzierung der Datenbankgröße, Verbesserung der Suchleistung, und das Auferlegen von Beschränkungen für den gültigen Datensatz, den ein Feld enthalten kann, unter anderem. Es ist auch empfehlenswert, dass alle Nachschlagetabellen ein Bit- oder ein boolesches Feld enthalten, das angibt, ob ein Datensatz in der Tabelle verwendet wird oder veraltet ist. Dieses Feld kann als Filter verwendet werden, um veraltete Elemente als Optionen in der Anwendungsoberfläche zu vermeiden.

Normalize or denormalize according to database type

In relationalen Datenbanken, die für traditionelle Anwendungen verwendet werden, ist die Normalisierung ein Muss. Es ist bekannt, dass die Normalisierung den benötigten Speicherplatz reduziert, indem Redundanzen vermieden werden. Es verbessert die Qualität der Informationen und bietet mehrere Tools zur Leistungsoptimierung bei komplexen Abfragen.

Bei anderen Arten von Datenbanken wird jedoch eine Technik angewendet, die als Denormalisierung bekannt ist. In dimensionalen Datenbanken, die als Data Warehouses verwendet werden, fügt die Denormalisierung den Schematabellen bestimmte nützliche redundante Informationen hinzu.

Obwohl es sich um gegensätzliche Konzepte zu handeln scheint, bedeutet Denormalisierung nicht, die Normalisierung rückgängig zu machen. Es ist eigentlich eine Optimierungstechnik, die auf ein Datenmodell angewendet wird, nachdem es normalisiert wurde, um das Schreiben und Berichten von Abfragen zu vereinfachen.

Designing physical models in parts

In einem Softwareentwicklungsprojekt präsentiert der Datenbankdesigner den Stakeholdern ein groß angelegtes Konzeptmodell, in dem keine Implementierungsdetails gezeigt werden. Um mit Entwicklern zu arbeiten, muss der Designer wiederum ein physisches Modell mit allen Details jeder Entität und jedes Attributs bereitstellen. Beide Modelle müssen jedoch nicht zu Beginn des Projekts vollständig erstellt werden.

Bei der Bewerbung agile Methoden, nimmt jeder Entwickler zu Beginn jedes Entwicklungszyklus eine oder mehrere User Stories, um während dieses Zyklus zu arbeiten. Die Aufgabe des Datenbankdesigners besteht darin, jedem Entwickler ein physisches Untermodell bereitzustellen, das nur die Objekte enthält, die er für eine Arbeitseinheit benötigt.

Am Ende jedes Entwicklungszyklus werden die während dieses Zyklus erstellten Teilmodelle zusammengeführt, so dass das vollständige physikalische Modell parallel zur Entwicklung der Anwendung Gestalt annimmt.

Making good use of views and indexes

Ansichten und Indizes sind zwei grundlegende Werkzeuge im Datenbankdesign, um die Anwendungsleistung zu verbessern. Die Verwendung von Ansichten ermöglicht die Handhabung von Abstraktionen, die Abfragen vereinfachen und unnötige Tabellendetails verbergen. Ansichten wiederum erleichtern Datenbank-Engines die Abfrageoptimierungsaufgaben, da sie es ihnen ermöglichen, vorauszusehen, wie Daten abgerufen werden, und die besten Strategien auszuwählen, um Abfrageergebnisse schneller bereitzustellen.

Indizes können die Leistung verbessern einer langsamen Abfrage basierend auf der Benutzererfahrung, sobald die Datenbank in Produktion ist. Die Indexerstellung kann jedoch als Teil der Datenbankentwurfsaufgaben durchgeführt werden, um die Anforderungen der Anwendung vorwegzunehmen.

Für die Erstellung von Indizes müssen Sie eine ungefähre Vorstellung von der Größe jeder Tabelle haben – in Bezug auf die Anzahl der Datensätze – und dann Indizes für die größeren Tabellen erstellen. Bei der Auswahl der Felder, die in einen Index aufgenommen werden sollen, müssen Sie hauptsächlich diejenigen berücksichtigen, die Fremdschlüssel darstellen und die als Filter in den Suchen verwendet werden.

Wenn Sie der Meinung sind, dass die Arbeit abgeschlossen ist, ist es an der Zeit, umzugestalten.

Das Design einer Datenbank kann immer verbessert werden. Wenn die Datenbank aufgrund neuer Anforderungen oder neuer Geschäftsanforderungen nicht geändert wird, ist dies eine gute Gelegenheit, Refactoring-Verfahren durchzuführen, die das Design verbessern. Refactoring bedeutet einfach das: Einführen von Änderungen, die ein Design verbessern, ohne die Semantik der Datenbank zu beeinträchtigen.

Es gibt viele Refactoring-Techniken zur Verbesserung des Designs einer Datenbank, die den Rahmen dieses Artikels sprengen würden, aber es ist gut zu wissen, dass sie existieren, um sie bei Bedarf zu verwenden.

Wenn Sie diese Best Practices-Liste immer zur Hand haben, wenn Sie eine Datenbank entwerfen müssen, können Sie die besten Ergebnisse erzielen, damit die Anwendungen immer erhalten bleiben optimale Leistung beim Datenzugriff.