Entwurfsmuster für relationale Datenbanken? [geschlossen]

Entwurfsmuster beziehen sich normalerweise auf objektorientiertes Entwurf.
Gibt es Entwurfsmuster zum Erstellen und Programmieren relationaler Datenbanken ?
Viele Probleme müssen sicherlich wiederverwendbare Lösungen haben.

Beispiele wären Muster für das Tabellendesign, gespeicherte Prozeduren, Trigger usw.

Gibt es ein Online-Repository für solche Muster, ähnlich wie bei martinfowler.com ?

Beispiele für Probleme, die Muster lösen könnten:

• Speichern hierarchischer Daten (z. B. einzelne Tabelle mit Typ gegenüber mehreren Tabellen mit 1: 1-Schlüssel und Unterschieden ...)
• Speichern von Daten mit variabler Struktur (z. B. generische Spalten vs xml vs begrenzte Spalte ...)
• Denormalisieren Sie Daten (wie es mit minimalen Auswirkungen geht, etc ...)

In Martin Fowlers Signature Series gibt es ein Buch mit dem Titel Refactoring Databases . Das bietet eine Liste von Techniken zum Refactoring von Datenbanken. Ich kann nicht sagen, dass ich so oft eine Liste von Datenbankmustern gehört habe.

Ich kann auch die Datenmodellmuster von David C. Hay und die nachfolgende A-Metadatenkarte nur empfehlen, die auf der ersten aufbaut und weitaus ehrgeiziger und faszinierender ist. Das Vorwort allein ist aufschlussreich.

Ein großartiger Ort, um nach vorgefertigten Datenbankmodellen zu suchen, ist Len Silverstons Data Model Resource Book Series, Band 1, enthält universell anwendbare Datenmodelle (Mitarbeiter, Konten, Versand, Einkäufe usw.). Band 2 enthält branchenspezifische Datenmodelle (Buchhaltung, Gesundheitswesen usw.), Band 3 enthält 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 eines Objekt- / Datenmodells gibt

Entwurfsmuster sind keine trivial wiederverwendbaren Lösungen.

Entwurfsmuster sind per Definition wiederverwendbar. Das sind Muster, die Sie in anderen guten Lösungen erkennen.

Ein Muster ist nicht trivial wiederverwendbar. Sie können Ihr Down-Design jedoch nach dem Muster implementieren.

Zu den relationalen Designmustern gehören Dinge wie:

1. Eins-zu-Viele-Beziehungen (Master-Detail, Eltern-Kind) -Beziehungen unter Verwendung eines Fremdschlüssels.

2. Viele-zu-Viele-Beziehungen mit einer Brückentabelle.

3. Optionale Eins-zu-Eins-Beziehungen, die mit NULL-Werten in der Spalte FK verwaltet werden.

4. Sternschema: Dimension und Fakt, OLAP-Design.

5. Vollständig normalisiertes OLTP-Design.

6. Mehrere indizierte Suchspalten in einer Dimension.

7. "Nachschlagetabelle", die PK, Beschreibung und Codewerte enthält, 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.

8. 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 vorverbundenen Dingen, die gegen die zweite und dritte Normalform verstoßen.

9. Array-Tabelle. Dies ist eine Tabelle, die die erste Normalform verletzt, indem sie ein Array oder eine Folge von Werten in den Spalten enthält.

10. Datenbank mit gemischter Nutzung. 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 - tu das nicht. Die Leute machen es trotzdem, also ist es immer noch ein Muster.

Die meisten Leute, die Datenbanken entwerfen, können leicht ein halbes Dutzend "Es ist eine andere von denen" rasseln; Dies sind Entwurfsmuster, die sie regelmäßig verwenden.

Dies beinhaltet keine administrativen und betrieblichen Verwendungs- und Verwaltungsmuster.

AskTom ist wahrscheinlich die hilfreichste Ressource für Best Practices in Oracle-DBs. (Normalerweise gebe ich einfach "asktom" als erstes Wort einer Google-Abfrage zu einem bestimmten Thema ein.)

Ich denke nicht, dass es wirklich angemessen ist, von Entwurfsmustern mit relationalen Datenbanken zu sprechen. Relationale Datenbanken sind bereits die Anwendung eines "Entwurfsmusters" auf ein Problem (das Problem besteht darin, "wie Daten unter Wahrung ihrer Integrität dargestellt, gespeichert und verarbeitet werden", und das Design ist das relationale Modell). Andere Ansätze (die allgemein als veraltet angesehen werden) sind die Navigations- und Hierarchiemodelle (und ich bin mir sicher, dass es viele andere gibt).

Allerdings könnten Sie "Data Warehousing" als ein etwas separates "Muster" oder einen Ansatz im Datenbankdesign betrachten. Insbesondere könnte Sie das Lesen des Star-Schemas interessieren .

Nach vielen Jahren der Datenbankentwicklung kann ich sagen, dass es einige Nein-Fragen und einige Fragen gibt, die Sie beantworten sollten, bevor Sie beginnen:

Fragen:

• Möchten Sie in Zukunft ein anderes DBMS verwenden? Wenn ja, dann werden keine speziellen SQL-Inhalte des aktuellen DBMS verwendet. Entfernen Sie die Logik in Ihrer Anwendung.

Verwendet nicht:

• Leerzeichen in Tabellennamen und Spaltennamen
• Nicht-Ascii-Zeichen in Tabellen- und Spaltennamen
• Bindung an einen bestimmten Klein- oder Großbuchstaben. Verwenden Sie niemals zwei 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 Äquivalente für die Unicode-Unterstützung, dann haben Sie keine Probleme mit Codepages.
• Geben Sie jeder Spalte einen eindeutigen Namen. Dies erleichtert das Auswählen der Spalte beim Verbinden. 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 oder mehrere Ressourcenpakete. Dies erleichtert den Wechsel zu einem anderen DBMS.
• Wirkt keinen Datentyp hart. 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 etwas vage, aber ich nehme an, sie UPSERTkönnte als Entwurfsmuster angesehen werden. Für Sprachen, die nicht implementiert werden MERGE, gibt es eine Reihe von Alternativen zur Lösung des Problems (sofern geeignete Zeilen vorhanden sind UPDATE; sonst INSERT).

Kommt darauf an, was du mit einem Muster meinst. Wenn Sie an Person / Firma / Transaktion / Produkt und dergleichen denken, dann ja - es sind bereits viele generische Datenbankschemata verfügbar.

Wenn Sie an Factory denken, Singleton ... dann nein - Sie brauchen keine davon, da sie für die DB-Programmierung zu niedrig sind.

Wenn Sie an die Benennung von Datenbankobjekten denken, fällt dies unter die Kategorie der Konventionen und nicht unter Design an sich.

Übrigens, S.Lott, Eins-zu-Viele- und Viele-zu-Viele-Beziehungen sind keine "Muster". Sie sind die Grundbausteine ​​des relationalen Modells.