Gilt YAGNI für das Datenbankdesign?

Question

In Code ist es in der Regel ziemlich einfach, neue Klassen hinzuzufügen, um zusätzliche Funktionen und dergleichen bereitzustellen. Ich habe ein ziemlich gutes Verständnis von Refactoring-Code und was damit verbunden ist, macht YAGNI im Allgemeinen Sinn für mich.

Was ich nicht so vertraut bin, ist mit einer relationalen Datenbank arbeiten und aktualisieren, sobald es bereitgestellt wird. Ich entwickle ein kleines Haustier-Projekt, das ich auf Release Early, Release Often praktizieren werde und ich frage mich, ob ich Daten in Betracht ziehen sollte, die nicht in der ersten Version verwendet werden, aber auf der Liste der geplanten Features ist? Ist es so einfach, Tabellen hinzuzufügen und Schemas zu optimieren, als neue Klassen hinzuzufügen? Oder sollte ich versuchen, Tische für Dinge aufzustellen, die ich vielleicht nutzen könnte, aber nicht in naher Zukunft planen?

Answer 1

Wenn Sie gute Tests haben, die die Datenbank trifft, würde ich YAGNI zu Ihrem Datenbankentwurf erweitern.

Im Allgemeinen ist es einfach, Spalten und Tabellen hinzuzufügen und sie sind nicht so einfach zu entfernen oder zu modifizieren. Berücksichtigen Sie dies beim Entwerfen von Tabellen (d. H. Wenn ein Kunde mehrere Benutzer haben kann, fügen Sie keine Benutzer-ID zu Ihrer Kunden-Tabelle hinzu. Machen Sie es beim ersten Mal richtig).

Answer 2

Meine Meinung ist, dass YAGNI für alles gilt, Codierung, Datenbank-Design, arbeiten rund um das Haus (meine Frau stimmt nicht mit mir vehement auf diese), und so weiter.

Jede DBMS-basierte Anwendung, an der ich je gearbeitet habe, wurde regelmäßig auf dem scea aktualisiert, so dass dies in Prozessen geplant werden sollte. Die Datenbankadministratoren werden den Teil "häufig freigeben" Ihres Vorschlags nicht mögen, da dies für sie mehr Arbeit bedeutet (oder Sie, wenn es sich um eine Datenbank ohne DBA handelt).

Aber dafür sind sie da.

Answer 3

Dies ist eine ausgezeichnete Frage. Ich persönlich habe herausgefunden, dass das Ändern eines Datenbankschemas und das Konvertieren aller Daten in die neue Darstellung weitaus schwieriger ist als das Refactoring von Code. So sehr, dass ich jedes Mal, wenn ich ein Projekt starte, das eine neue Datenbank verwendet, Zeit brauche, bevor ich mich hinsetze und irgendeinen Code schreibe, um meine Spezifikation so gründlich wie möglich zu machen. Was dies oft mit sich bringt, sind Features zu antizipieren und Unterstützung für sie in die Datenbank aufzunehmen, auch wenn ich nicht vorhabe, sie sofort zu implementieren.

Wenn Sie ein Framework oder eine andere ähnliche Schicht verwenden, die einen Mechanismus zum Ändern der Datenbank bereitstellt, können Sie mit der Datenbankreformierung etwas flexibler sein. Wenn Sie aber gerade SQL schreiben, würde ich Ihnen empfehlen zu investieren eine bescheidene Zeit, um ein Schema zu entwerfen und zu implementieren, das in Zukunft weniger Änderungen erfordert.

Answer 4

Das Prinzip gilt weiterhin. Sie müssen sich keine Gedanken darüber machen, Felder zu Tabellen usw. hinzuzufügen, bis Sie viele Daten haben. Ziemlich viele Daten. Sich zu früh um die Details von Indizierung und Abfrageplänen zu kümmern, ohne tatsächliche Daten zu sehen, wird oft Zeitverschwendung sein und später sogar zu Architekturproblemen führen.

Leider kann es nach einem Produktions-Release mit dem Datenbank-Design meckern, wenn ein guter Test/Release-Prozess nicht befolgt wird. Also noch mehr als Code, Sie wollen es erstmal mit einer Datenbank richtig machen.

Mit Datenbanken möchten Sie planen, um die Daten zu erhalten sowie sie zu speichern und zu speichern. Wenn Ihre "geplanten" Funktionen Reporting beinhalten, wird das das Design der Datenbank sehr beeinflussen Plan dafür.

Es ist nicht so einfach, ein Schema wie das Hinzufügen einer Klasse zu optimieren, aber es ist machbar.

Insgesamt gilt YAGNI immer noch.

Answer 5

Richten Sie nicht die Tabellen ein, die Sie noch nicht benötigen. Ein Teil des Grundes hinter YAGNI ist, dass Sie nicht die richtigen Dinge voraussagen werden, die Sie benötigen. Sie können problemlos neue Tabellen hinzufügen, vorhandene Tabellen ändern usw., wenn Sie sie ändern müssen.

Ein gutes Framework sollte einige Tools zum Ausführen migrations haben, mit denen Sie Ihre Datenbank einfach und automatisch aktualisieren und downgraden können. Wenn Sie dies an Ort und Stelle haben und ziemlich vorsichtig mit Ihrem Design sind, sollten Sie in der Lage sein, Ihren Weg dahin umzugestalten, wo Sie sein müssen, anstatt zu versuchen, im Voraus alles zu erfinden, was Sie jemals brauchen werden.

Answer 6

Es gibt eine ganze Reihe von agilen Überlegungen zum Datenbankdesign und zur Implementierung. Sie könnten interessiert sein, durch die best practices unter www.agiledata.org für einige von Scott Ambler's Gedanken zu diesem Thema zu suchen. Für mich selbst lasse ich das Design der Datenbank im Allgemeinen wachsen, während sich die Anwendung entwickelt. Ich erstelle selten Tabellen im Voraus. Ausnahmen davon wären Dinge wie Auditing und Berechtigungen, Dinge, die sich über das gesamte Design erstrecken. Ich werde darüber nachdenken, wie ich diese Dinge umsetzen kann, auch wenn ich im Voraus keine Tabellen für sie erstelle. Querschnittsthemen beeinflussen die Gestaltung von Tischen, auch wenn diese nicht immer die ersten sind.

Answer 7

Datenbank-Design ist wie jede andere Art von Design. Ihr Verständnis wächst inkrementell und mit besserem Verständnis entsteht ein sich entwickelndes Schema.

Ich wünschte, es wäre einfacher zu erklären, wie es tatsächlich eine konzeptionelle Grundlage für das Design relationaler Datenbankschemas gibt. Das einzige Werkzeug, das es wirklich modelliert, ist die Objektrollenmodellierung, die lange Zeit auf sich warten ließ. Das bekannteste Werkzeug war Visiomodeler. Um einen Eindruck davon zu bekommen, hier sind ein paar Links zu Scott Ambler und Scot Becker Aber die Schlussfolgerung, die man ziehen würde, ist, dass Objekt-Modeling-Typ Assertions direkt zu einem spezifischen relationalen logischen Modell führen; Daher muss sich das Schema ändern, wenn sich Ihr konzeptionelles Modell ändert.

In der Praxis können Ihre rdbms ziemlich viel Flex handhaben, wenn Sie mit Transformationsausdrücken wirklich vertraut sind. und es lohnt sich, gut darin zu werden.

Hinweis: Ich denke, dass SQL-Vermeidungstechniken wie LINQ und Objektrelationsmodelle nur ein Hindernis für ein sich entwickelndes Design sein werden. Ich kann mich irren. Es gibt Grund zu der Hoffnung, dass das Entity Framework von Microsoft Object Role Modeling umfasst; aber ich habe nur schräge Hinweise auf die Möglichkeit gesehen.

Answer 8

Es gibt eine konzeptionelle Grundlage für das Datenbankdesign.

Im klassischen Datenbankdesign gibt es drei Modelle: konzeptionell, logisch und physisch.

Das konzeptionelle Modell ergibt sich aus der Anforderungsanalyse und entwickelt sich, wenn sich der zugrundeliegende Gegenstand entwickelt oder wenn sich das Verständnis des Gegenstands entwickelt. Das konzeptionelle Modell legt elementare Daten wie Form und Semantik fest, behandelt jedoch nicht solche Probleme wie die Tabellenzusammensetzung.

Das logische Modell verwendet das relationale Datenmodell. Es kann aus dem konzeptionellen Modell abgeleitet werden, aber es befasst sich auch mit der Zusammensetzung der Beziehungen. Normalisierung und andere Kompositionsprobleme kommen hier zum Tragen. Das logische Modell nimmt das Tabellendesign und die Abfragen und Aktualisierungen der Anwendung vorweg.

Das physische Modell implementiert Beziehungen als Tabellen und fügt auch alle anderen Features wie Indizes, Tablespaces usw. hinzu.benötigt, um die Datenbank tatsächlich zu erstellen. Es wird vom logischen Modell abgeleitet, aber Datenvolumen, Auslastung, Leistung und Speicherplatz spielen alle eine Rolle.

Das klingt lang und langweilig, aber es ist tatsächlich schnell, wenn Sie wissen, wie es geht. Das Ganze kann in wenigen Wochen erledigt werden, während der Rest des Teams immer noch über funktionale Spezifikationen debattiert. Für ein wirklich kleines Projekt (6 Tische, 50 Spalten) ist es in Tagen möglich, nur mit Bleistift und Papier. Für größere Projekte gibt es Werkzeuge, die das Design automatisieren, weniger fehleranfällig machen und einfach grafisch darstellen.

Aber was passiert, wenn Sie feststellen, dass das konzeptionelle Modell ungenau oder unvollständig war und die anderen beiden Modelle und die Datenbank selbst geändert werden müssen? Das ist, wo Data Independence zur Rettung kommt. Die Datenunabhängigkeit macht für das Datenbankdesign aus, was die Kapselung für das Objektdesign tut. Es verhindert nämlich, dass sich eine geringfügige Anpassung an einem Ort über die gesamten Anwendungsobjekte ausbreitet. Objekte sind nur von den Daten abhängig, die sie verwenden.

Wenn eine neue Tabelle zu einem Schema hinzugefügt werden muss, ist die Wahrscheinlichkeit, dass eine Anwendung beschädigt wird, verschwindend gering. Auch wenn eine vorhandene Tabelle geändert werden muss, sehen Abfragen, die nur die alten Spalten verwenden, keinen Unterschied. Auch wenn Objekte von der Änderung abhängig sind, können Sie der geänderten Tabelle immer noch einen neuen Namen geben und dann eine Ansicht mit dem alten Namen erstellen, sodass die alte Tabelle immer noch angezeigt wird.

Und physikalische Daten Unabhängigkeit ist fast in einem guten DBMS abgeschlossen. Sie können Daten reorganisieren, Indizes hinzufügen und löschen, und Sie sollten keine Anwendung ändern müssen.

Kurz gesagt, kann das Änderungsmanagement hervorragend mit den wirklich guten DBMS-Produkten durchgeführt werden. Leider wissen viele DBAs und Programmierer nicht, wie sie diese DBMS-Funktionen adäquat nutzen können, obwohl sie schon seit Jahren existieren.