Entwurfsmuster für relationale Datenbanken?
Designmuster beziehen sich normalerweise auf objektorientiertes Design.
Gibt es Entwurfsmuster zum Erstellen und Programmieren relationale Datenbanken ?
Viele Probleme müssen sicher wiederverwendbare Lösungen haben.
Beispiele hierfür sind Muster für das Entwerfen von Tabellen, gespeicherte Prozeduren, Trigger usw.
Gibt es ein Online-Repository für solche Muster, ähnlich wie martinfowler.com ?
Beispiele für Probleme, die Muster lösen könnten:
- Hierarchische Daten speichern (z. B. einzelne Tabelle mit Typ im Vergleich zu mehreren Tabellen mit 1: 1-Schlüssel und Unterschieden ...)
- Speichern von Daten mit variabler Struktur (z. B. generische Spalten vs xml vs begrenzte Spalte ...)
- Daten denormalisieren (wie es mit minimaler Auswirkung gemacht wird, etc ...)
In Martin Fowlers Signature Series gibt es ein Buch mit dem Titel Refactoring Databases . Hier finden Sie eine Liste von Techniken zum Umgestalten von Datenbanken. Ich kann nicht sagen, dass ich so oft eine Liste von Datenbankmustern gehört habe.
Ich kann David C. Hay's Data Model Patterns und das Follow-up A Metadata Map sehr empfehlen, das auf dem ersten aufbaut und weitaus ehrgeiziger und faszinierender ist. Das Vorwort allein ist aufschlussreich.
Ein weiterer guter Ort, um nach vordefinierten Datenbankmodellen zu suchen, ist Len Silverstons Datenmodell-Ressourcenbuchserie Band 1 enthält allgemein anwendbare Datenmodelle (Mitarbeiter, Konten, Versand, Einkäufe usw.), Band 2 enthält branchenspezifische Datenmodelle (Rechnungswesen, Gesundheitswesen usw.), Band liefert Datenmodellmuster.
Während sich dieses Buch angeblich mit UML und Objektmodellierung befasst, bietet Peter Coads Modellierung in Farbe mit UML einen "Archetyp" -gesteuerten Prozess der Entitätsmodellierung, ausgehend von der Annahme, dass es 4 Kernarchetypen für jedes Objekt gibt /Datenmodell
Hier ist ein Link zu einem Gentleman, der mehrere hundert kostenlose Datenbankschemata entwickelt hat.
http://www.databaseanswers.org/data_models/
Wenn Sie eine Datenbank schnell erstellen müssen, erhalten Sie möglicherweise einen Ausgangspunkt in Bezug auf die Tabellen und Beziehungen in einem bestimmten Schema. Denken Sie daran, dass Sie diesen Ausgangspunkt wahrscheinlich ändern müssen. Ich habe es sehr nützlich gefunden.
Zweitens enthält das SQL Server-Magazin gelegentlich eine Spalte mit dem Namen "The Data Modeler", die sehr lehrreich ist und häufig vollständige Schemata für ein bestimmtes System enthält.
Entwurfsmuster sind keine trivial wiederverwendbaren Lösungen.
Entwurfsmuster sind per Definition wiederverwendbar. Sie sind Muster Sie erkennen in anderen guten Lösungen.
Ein Muster ist nicht trivial wiederverwendbar. Sie können Ihr Daunendesign jedoch nach dem Muster implementieren.
Relationale Designmuster umfassen Dinge wie:
Eins-zu-Viele-Beziehungen (Master-Detail, Eltern-Kind-Beziehungen) unter Verwendung eines Fremdschlüssels.
Viele-zu-Viele-Beziehungen zu einer Brückentabelle.
Optionale Eins-zu-Eins-Beziehungen, die mit NULL-Werten in der FK-Spalte verwaltet werden.
Sternschema: Dimension und Fakt, OLAP Design.
Vollständig normalisiertes OLTP Design.
Mehrere indizierte Suchspalten in einer Dimension.
"Nachschlagetabelle" mit PK, Beschreibung und Codewerten, die von einer oder mehreren Anwendungen verwendet werden. Warum Code haben? Ich weiß es nicht, aber wenn sie verwendet werden müssen, ist dies eine Möglichkeit, die Codes zu verwalten.
Uni-Tisch. [Einige nennen dies ein Anti-Muster; Es ist ein Muster, manchmal ist es schlecht, manchmal ist es gut.] Dies ist eine Tabelle mit vielen vorgefügten Elementen, die gegen die zweite und dritte Normalform verstoßen.
Array-Tabelle. Dies ist eine Tabelle, die gegen die erste Normalform verstößt, indem sie ein Array oder eine Folge von Werten in den Spalten enthält.
Mixed-Use-Datenbank. Dies ist eine für die Transaktionsverarbeitung normalisierte Datenbank mit vielen zusätzlichen Indizes für die Berichterstellung und Analyse. Es ist ein Anti-Muster - mach das nicht. Die Leute machen es trotzdem, es ist also immer noch ein Muster.
Die meisten Leute, die Datenbanken entwerfen, können mit Leichtigkeit ein halbes Dutzend "Es ist ein anderes von denen" rasseln. Dies sind Designmuster, die sie regelmäßig verwenden.
Und dies schließt administrative und betriebliche Verwendungs- und Verwaltungsmuster nicht ein.
Schauen Sie sich diesen Blog an - The Database Programmer .
Er beschreibt einige Datenbankmuster .
Joe Celkos Bücher eignen sich hervorragend für solche Dinge, insbesondere "SQL for Smarties". Er hat einige innovative Lösungen für häufig auftretende Probleme, von denen die meisten wiederverwendbare Entwurfsmuster sind.
AskTom ist wahrscheinlich die hilfreichste Ressource für Best Practices für Oracle-DBs. (Normalerweise gebe ich "asktom" als erstes Wort einer Google-Abfrage zu einem bestimmten Thema ein.)
Ich halte es nicht für angebracht, von Entwurfsmustern mit relationalen Datenbanken zu sprechen. Relationale Datenbanken sind bereits die Anwendung eines "Entwurfsmusters" auf ein Problem (das Problem besteht darin, "Daten unter Wahrung ihrer Integrität darzustellen, zu speichern und zu bearbeiten", und das Design ist das relationale Modell). Andere Ansätze (die allgemein als veraltet angesehen werden) sind das Navigations- und das hierarchische Modell (und ich bin mir sicher, dass es viele andere gibt).
Allerdings können Sie "Data Warehousing" als ein etwas anderes "Muster" oder einen anderen Ansatz im Datenbankdesign betrachten. Insbesondere könnte Sie das Sternschema interessieren.
Nach vielen Jahren der Datenbankentwicklung kann ich sagen, dass es einige Nein-Antworten und einige Fragen gibt, die Sie beantworten sollten, bevor Sie beginnen:
Fragen:
- Möchten Sie in Zukunft ein anderes DBMS verwenden? Wenn ja, dann wird kein spezielles SQL-Zeug des aktuellen DBMS verwendet. Entfernen Sie die Logik in Ihrer Anwendung.
Benutzt nicht:
- leerzeichen in Tabellennamen und Spaltennamen
- Nicht-ASCII-Zeichen in Tabellen- und Spaltennamen
- bindung an einen bestimmten Klein- oder Großbuchstaben. Verwenden Sie niemals 2 Tabellen oder Spalten, die sich nur in Klein- und Großbuchstaben unterscheiden.
- verwendet keine SQL - Schlüsselwörter für Tabellen - oder Spaltennamen wie "FROM", "BETWEEN", "DELETE" usw
Empfehlungen:
- Verwenden Sie NVARCHAR oder ein gleichwertiges Programm für die Unicode-Unterstützung, dann haben Sie keine Probleme mit Codepages.
- Geben Sie jeder Spalte einen eindeutigen Namen. Dies erleichtert die Auswahl der Spalte beim Zusammenfügen. Es ist sehr schwierig, wenn jede Tabelle eine Spalte "ID" oder "Name" oder "Beschreibung" hat. Verwenden Sie XyzID und AbcID.
- Verwenden Sie für komplexe SQL-Ausdrücke ein Ressourcenpaket oder eine Entsprechung. Dies erleichtert den Wechsel zu einem anderen DBMS.
- Wirkt nicht hart auf irgendeinen Datentyp. Ein anderes DBMS kann diesen Datentyp nicht haben. Zum Beispiel haben Oracle-Daes nicht nur eine SMALLINT-Nummer.
Ich hoffe, das ist ein guter Ausgangspunkt.
Ihre Frage ist ein bisschen vage, aber ich nehme an, UPSERT könnte als Entwurfsmuster angesehen werden. Für Sprachen, die MERGE nicht implementieren, eine Reihe von Alternativen, um das Problem zu lösen (wenn geeignete Zeilen vorhanden sind, UPDATE; sonst INSERT ) existieren.
Kommt darauf an, was du mit einem Muster meinst. Wenn Sie an Person/Firma/Transaktion/Produkt und dergleichen denken, dann sind bereits viele generische Datenbankschemata verfügbar.
Wenn Sie an Factory, Singleton ... denken, dann nein - Sie brauchen keines davon, da es für die DB-Programmierung zu niedrig ist.
Wenn Sie an die Benennung von Datenbankobjekten denken, fällt dies in die Kategorie der Konventionen und nicht in das eigentliche Design.
Übrigens, S.Lott, Eins-zu-Viele- und Viele-zu-Viele-Beziehungen sind keine "Muster". Sie sind die Grundbausteine des relationalen Modells.
Dieses Buch sieht interessant aus
Title: Data Patterns
By: Microsoft Corporation
Publisher: Microsoft Press
Pub. Date: December 21, 2004
Print ISBN-13: 978-0-7356-2200-5