it-swarm-eu.dev

Sollten Sie die Datenbank entwerfen, bevor der Anwendungscode geschrieben wird?

Was ist der einfachste und effizienteste Weg, eine Datenbank zu entwerfen? Aus meiner Sicht gibt es einige Optionen für das Datenspeicherdesign einer Anwendung:

  1. Entwerfen Sie die Datenbank so gut wie möglich bevor Sie einen Anwendungscode schreiben. Dies gibt Ihnen den Vorteil einer Basisdatenstruktur, an der Sie arbeiten können. Der Nachteil davon ist meiner Meinung nach, dass Sie viele Änderungen als Anwendungsspezifikationen haben werden, die sich auf das Was/Wo/Wie von Datenänderungen auswirken während des gesamten Anwendungsentwicklungszyklus.
  2. Entwerfen Sie die Datenbank so, wie die Anwendung zum Tragen kommt . Wenn Sie beim Schreiben der Anwendung einige Datenbankobjekte benötigen, entwickeln Sie die Datenbank parallel (chronologisch) zur Anwendung. Die Vorteile wären weniger Änderungen an der Datenbankstruktur, wie ich es sehe. Der Nachteil wäre die Aufteilung von Zeit und Entwicklungsaufwand zwischen Anwendungscode und Datenbankentwicklung.

Was ist Ihrer Erfahrung nach die produktivste und effizienteste Methode?

57
Thomas Stringer

Neben anderen Antworten ...

Erfassen Sie zuerst Ihr konzeptionelles Modell sollte Umfang und Anforderungen definieren. Daraus können Sie Ihre logischen und physischen Datenmodelle ableiten.

Sobald dies größtenteils statisch ist, haben Sie eine stabile Datenbank, gegen die Sie Ihre Anwendung erstellen können. Dies widerspricht Ihrer ersten Option.

Ihr zweiter Punkt endet in einem unordentlichen, nicht zu wartenden Schlammball . Das Datenmodell wird niemals repariert: Wenn Sie es nicht im Voraus entworfen haben, haben Sie keine Zeit, es vor dem Versand zu reparieren. Sie werden zu beschäftigt sein, Dinge zusammen zu hacken.

Kleinere Änderungen am Schema, Kombinieren oder Teilen von Tabellen, Ändern von Beziehungen usw. werden vorgenommen, aber auf lokalisierten "Inseln", und Ihr Modell + Basisdesign bleibt unverändert.

42
gbn

Es wird Ihnen schwer fallen, eine moderne Softwareabteilung zu finden, die keine Variante von Agile betreibt. DBAs stecken im Vergleich dazu im dunklen Zeitalter fest, mit der Art des Denkens, dass @ RobPallers Antwort immer noch alltäglich ist.

Das Ändern eines Datenbankschemas war noch nie so einfach wie das Ändern von Code. Aus diesem Grund zögerte man, einen agilen Ansatz für die Datenbankentwicklung und -wartung zu verfolgen. Jetzt, da wir die Werkzeuge und Techniken haben, um ähnlich wie Entwickler zu arbeiten, sollten wir dies auf jeden Fall tun. Nur weil es nicht einfach ist, das Schema zu ändern, heißt das nicht, dass Sie es nicht können und dass Sie es nicht sollten.

Ich befürworte keinen willkürlichen Ansatz für das Datenbankdesign (siehe Kommentare), sondern lediglich einen Ansatz, der den eines agilen Entwicklungsteams besser widerspiegelt. Wenn Sie Teil eines agilen Projekts sind, werden Sie keine Anforderungen an die Arbeit haben, die in Zukunft auftreten können ( oder auch nicht ). Entwerfen Sie also für das, was Sie wissen, dass es benötigt wird, nicht für das, was möglicherweise erforderlich ist Sein.

Ich denke, das bringt meine Stimme mit Ihrer Option 2 und ich vermute, dass ich in dieser Frage in der Kälte stehe!

27

Ihr logisches Datenmodell sollte die Geschäftsanforderungen Ihrer Anwendung effektiv erfassen. Ihr physisches Datenbankdesign sollte auf dem logischen Datenmodell basieren, kombiniert mit den notwendigen Änderungen, die Sie als DBA für erforderlich halten, um die Effizienz Ihres RDBMS zu maximieren.

Wenn Sie feststellen, dass Sie während des gesamten Softwareentwicklungszyklus Ihrer Anwendung zahlreiche Änderungen am zugrunde liegenden Datenbankdesign vornehmen müssen, weist dies auf zwei Dinge hin:

  1. Scope Creep - Sie erlauben, dass neue Anforderungen zu einem unangemessenen Zeitpunkt eingeführt werden.
  2. nzureichende Geschäftsanforderungen - Ihre Datenmodellierer (oder Systemanalysten) haben die Anforderungen der Geschäftsanalysten nicht ausreichend übersetzt. Dies führte zu einem unvollständigen oder falschen Datenmodell, um die Anforderungen Ihrer Anwendung zu erfüllen.

Abgesehen davon ist es nicht ungewöhnlich, dass eine Anwendung nach der Übergabe an die Produktion iterativ am Datenmodell geändert werden muss, um die natürliche Entwicklung der Anwendung oder der zugrunde liegenden Geschäftsprozesse zu unterstützen.

Hoffe das hilft.

12
RobPaller

Ich hatte den Luxus, mehrere Datenbanken mittlerer Komplexität zu entwerfen, die alle in Unternehmen verwendet werden, mit verschiedenen Frontends, einschließlich Web, Access und C #.

Normalerweise habe ich mich hingesetzt und das Datenbankschema im Voraus ausgearbeitet. Das hat mir immer am meisten Sinn gemacht. Es gab jedoch keinen einzigen Fall, in dem ich keine Änderungen vorgenommen, keine neuen Tabellen hinzugefügt oder mit Aspekten gelebt habe, die mich störten und im Grunde zu spät waren, um sie zu beheben.

Ich glaube nicht, dass die Heilung darin besteht, zuerst den Code zu schreiben. Und ich denke nicht, dass das Problem "unzureichende Geschäftsanforderungen" sind oder zumindest nicht eines, das vollständig hätte gelöst werden können. Die Benutzer wissen nicht, was sie brauchen, und ich kann sie nicht dazu bringen, härter zu denken, klüger oder bewusster zu sein oder meine Fragen besser zu beantworten. Oder sie streiten sich und ich werde angewiesen, etwas auf eine bestimmte Weise zu tun.

Die Systeme, die ich baue, befinden sich normalerweise in neuen Bereichen, in die noch niemand zuvor gegangen ist. Ich habe nicht das Buy-In von der Organisation, die Ressourcen oder die Werkzeuge, um die Art von Arbeit zu erledigen, die ein Entwicklungsteam von hochkarätigen Designprofis leisten könnte, die als Team zehnmal so viel bezahlt bekommen, wie ich für den Aufbau von Dingen verdiene zweimal die Zeit.

Ich bin gut in dem, was ich tue. Aber es gibt nur einen von mir, der dies in einer Umgebung tut, die "keine Entwicklung betreibt".

Trotzdem werde ich besser darin, Geschäftsregeln zu entdecken. Und ich sehe eine Art dritte Option:

Zeichnen Sie vor dem Entwerfen der Datenbank und vor dem Schreiben von Code grobe Bildschirme, die zeigen, wie die Anwendung funktioniert. Sie müssen von Hand gezeichnet werden, um zu verhindern, dass jemand Kommentare zu Schriftart, Größe oder Abmessungen abgibt - Sie möchten nur eine Funktion.

Mit Transparentfolien und Papierstücken können Sie ein- und auswechseln, eine Person ist der Computer, zwei sind nicht-technische Fachexperten (zwei sprechen laut) und eine Person als Moderator, der Notizen macht und zeichnet die Benutzer über ihre Denkprozesse und Verwirrungen informieren. Die Benutzer "klicken" und ziehen und schreiben in Felder, der "Computer" aktualisiert den Bildschirm und jeder kann das Design erleben. Sie werden Dinge lernen, die Sie bis weit in den Entwicklungsprozess hinein sonst nicht hätten lernen können.

Vielleicht widerspreche ich mir selbst - vielleicht ist es IS bessere Ermittlung von Anforderungen. Aber die Idee ist, die Anwendung zuerst zu entwerfen, ohne Code zu schreiben. Ich habe damit begonnen, dies in kleinem Maßstab zu tun, und es funktioniert ! Trotz der Probleme in meiner Umgebung hilft es mir, die Datenbank von Anfang an besser zu gestalten. Ich erfahre, dass eine Spalte in eine neue übergeordnete Tabelle verschoben werden muss, da es mehrere Typen gibt. Ich erfahre, dass der Arbeitsvorrat Daueraufträge haben muss, die nicht zutreffen Ich komme aus dem integrierten Bestellsystem. Ich lerne alle möglichen Dinge!

Meiner Meinung nach ist dies ein großer Gewinn.

11
ErikE

Für die meisten Zwecke würde ich Option 2 wählen: Erstellen Sie die Datenbank parallel zu den anderen Komponenten. Wenn immer möglich, gehen Sie iterativ vor und liefern Sie End-to-End-Funktionen, während Sie jedes Stück erstellen.

Dies erfordert ein gewisses Maß an Projektdisziplin. Wenden Sie die Normalisierung jedes Mal rigoros an (Boyce-Codd/Fünfte Normalform), wenn Sie die Datenbank ändern, damit Sie die Qualität erhalten und kein Ad-hoc- und inkonsistentes Modell erhalten. Seien Sie so aggressiv wie möglich mit Geschäftsregeln und damit verbundenen Datenbankbeschränkungen. Im Zweifelsfall ist es besser, eine Einschränkung frühzeitig durchzusetzen - Sie können sie später jederzeit entfernen. Seien Sie intelligent bei der Reihenfolge, in der Sie Architekturkomponenten implementieren, um die technische Verschuldung zu minimieren. Haben Sie eine Reihe guter Richtlinien für das Datenbankdesign, auf die sich das gesamte Entwicklerteam einlässt.

All dies muss natürlich mit anderen guten Entwicklungspraktiken einhergehen: kontinuierliche Integration, Testautomatisierung und vor allem aus Datenbanksicht die Erstellung von Testdaten. Die Erstellung von Testdaten mit realistischen Daten sollte in jeder Iteration unbedingt erfolgen.

10
nvogel

In der Welt der Architektur wurde der Ausdruck "Form folgt Funktion" geprägt und später beim Bau hoher Gebäude eingehalten. Gleiches sollte für die DB-Infrastruktur und die Anwendungsentwicklung gelten.

Stellen Sie sich vor, Sie schreiben eine App und entscheiden spontan, dass Sie hier und dort einen Tisch benötigen. Wenn Ihre App fertig ist, wird eine große Anzahl von Tabellen als Arrays behandelt. Wenn Sie alle Tische nebeneinander betrachten, scheinen die Tische definitiv keinen Reim oder Grund zu haben.

Leider nehmen einige Entwickler-Shops so etwas wie Memcached auf, laden es mit Daten in RAM (behandelt es also wie ein Daten-Conduit) und haben eine Datenbank wie MySQL oder PostgreSQL, die sich einfach so verhält eine Datenspeichereinheit.

Der Anreiz für die Verwendung einer Datenbank sollte darin bestehen, sie richtig zu betrachten: als RDBMS. Ja, ein Relational Datenbankverwaltungssystem. Wenn Sie ein RDBMS verwenden, sollte Ihr Ziel im Voraus nicht nur darin bestehen, Tabellen für die Speicherung, sondern auch für den Abruf einzurichten. Die Beziehungen zwischen Tabellen sollten nach den Daten modelliert werden, die Sie sehen möchten, und wie sie dargestellt werden. Dies sollte auf der Kohärenz und Integrität der Daten zusammen mit bekannten Geschäftsregeln beruhen. Diese Geschäftsregeln können in Ihrer App (Perl, Python, Ruby, Java usw.) oder in der Datenbank codiert werden.

FAZIT

Ich würde auf jeden Fall Option 1 wählen. Es erfordert eine ordnungsgemäße Planung, Datenmodellierung und laufende Datenanalyse. Dies sollte jedoch auf lange Sicht Datenbankänderungen minimieren.

9
RolandoMySQLDBA

Ich denke, es sollte gemacht werden, bevor es einen tatsächlichen Code für die Anwendung gibt, aber nicht bevor die Anwendung entworfen wurde.

Mein typischer Workflow, wenn ich alleine arbeite, ist:

  1. Bestimmen Sie, was die Anwendung tun muss
  2. Überprüfen Sie, ob eine der Aufgaben für wiederverwendbare Komponenten aufgeschlüsselt werden kann
  3. Bestimmen Sie, wie jede Aufgabe mit dem Datenspeicher interagieren muss - welche Art von Fragen werden sie an die Daten stellen, wie oft werden sie schreiben usw.
  4. Entwerfen Sie die Datenbank so, dass sie alle Fragen beantworten kann, die wir ihr stellen müssen, und dass sie für die häufigsten Aufgaben eine gute Leistung erbringt.
  5. Schreiben Sie die Anwendung.

Da ich häufig als Teil eines Teams arbeite und wir geografisch (und über Zeitzonen hinweg) verteilt sind, haben wir in der Regel ein erstes Kickoff-Meeting:

  1. Bestimmen Sie, was die Anwendung tun muss.
  2. Bestimmen Sie, wo gute Punkte die Anwendung in eigenständige Komponenten aufteilen sollen
  3. Bestimmen Sie, wie jede Komponente mit den anderen interagieren muss.
  4. Vereinbaren Sie für jede Interaktion eine API.

Dann kehren wir nach Hause zurück, schreiben unser Teil und wenn eine Komponente ihren eigenen lokalen Speicher benötigt, solange der Betreuer für dieses Teil die API für ihr Modul konsistent hält. Der Hauptdatenspeicher wird als Modul mit einer eigenen API behandelt, und es wird erwartet, dass Benutzer darauf schreiben. (In Fällen, in denen die DB-Geschwindigkeit kritisch ist, sind die Tabellendefinitionen die API. Wenn Änderungen vorgenommen werden, verwenden wir Ansichten oder einen anderen Mechanismus, um die ältere Version darzustellen, bis alle Module aktualisiert werden können.)

9
Joe

Ich denke an die folgende Regel: "Sie können nur die Informationen aus der Datenbank abrufen, für die Sie Daten generieren müssen". Also entwerfe ich zuerst die Datenbank, später den Code.

Warum? Egal welche Metodologie/Sprache/Toolset ich verwende, wenn alle relevanten Daten gut entworfen und in DB gespeichert sind, kann ich sie abrufen. Egal ob in C #/Delphi/FORTRAN/COBOL/Assembly/VBA oder Crystal Reports; OO entworfen oder Ereignis/Daten/was auch immer gesteuert; agil oder Wasserfall. Wenn die Daten vorhanden sind, kann ich sie abrufen, wenn die von mir verwendeten Tools eine Verbindung zur Datenbank herstellen können. Ich kann die Verkaufsberichte erstellen wenn ich die Aufträge für die Einnahmen des Quartals AUSWÄHLEN kann - auch wenn ich sie byteweise auf Assembly schreiben muss.

Wenn die relevanten Daten nicht vorhanden sind oder auch wenn sie vorhanden, aber (un) strukturiert sind, kann ich die benötigten Informationen nicht abrufen - wie kann ich sie codieren?

8
Fabricio Araujo

Wie immer kommt es darauf an;)

Angenommen, wir haben einen kleinen funktionierenden Prototyp, der in Python] entwickelt wurde und flache Dateien verwendet, und die Benutzer sind mit den Funktionen des Prototyps zufrieden. Wir müssen also nur Folgendes tun Produzieren Sie es mit RDBMS als Back-End. Wenn dies der Fall ist, ist zu erwarten, dass es beim ersten Mal richtig gemacht wird - das Problem ist klein und klar definiert. In solchen Fällen ist es möglich, im Voraus zu entwerfen.

Wenn wir andererseits die Anforderungen in einer agilen Umgebung entdecken, benötigen wir einige Iterationen, um sie besser zu verstehen. In solchen Situationen entwickelt sich die Datenbank mit dem Rest der Anwendung. Das machen wir normalerweise. Da wir live OLTP - Tabellen ohne Ausfallzeiten und mit geringem Risiko umgestalten können, sind wir mit der Möglichkeit von Datenbankumgestaltungen zufrieden.

7
A-K