it-swarm.com.de

Code First vs. Database First

Wenn ich die Software entwerfe und erstelle, an der ich arbeite, entwerfe und erstelle ich normalerweise zuerst die Back-End-SQL-Tabellen und gehe dann zur eigentlichen Programmierung über. Das Projekt, an dem ich gerade arbeite, hat mich allerdings völlig verwirrt. Dies ist wahrscheinlich auf einen Mangel an guten, soliden Anforderungen zurückzuführen, aber diesmal kann ich leider wenig dagegen tun. Es ist eine Art "Mach es einfach" -Situation ... aber ich schweife ab.

Ich denke darüber nach, meinen Workflow auf den Kopf zu stellen und zuerst die UI- und Datenmodellklassen zu erstellen, in der Hoffnung, dass mir durch das Ausarbeiten klar wird, wie mein Datenbankschema letztendlich aussehen wird. Ist das eine gute Idee? Ich bin nervös, dass ich am Ende eine Benutzeroberfläche habe und immer noch keine Ahnung habe, wie ich die Datenbank strukturieren soll.

Wenn jemand neugierig ist, verwende ich SQL Server als Backend und MS Access als Frontend-Anwendung. (Zugang ist auch nicht meine Wahl ... also bitte hasse es nicht so sehr.)

78
RubberDuck

Was war zuerst da, der Prozess oder die von diesem Prozess verwendeten Daten? Ich weiß, dass dies eine Art "Huhn oder das Ei" -Frage ist, aber im Fall von Software glaube ich, dass dies der Prozess ist.

Sie können Ihr Datenmodell beispielsweise schrittweise aufbauen, indem Sie jeweils einen einzelnen Anwendungsfall mit nur speicherinterner Persistenz (oder etwas so einfach zu implementierendem) implementieren. Wenn Sie der Meinung sind, dass Sie genügend Anwendungsfälle implementiert haben, um die grundlegenden Entitäten zu skizzieren, können Sie die In-Memory-Persistenz durch eine echte Datenbank ersetzen und das Schema dann weiter verfeinern, während Sie fortfahren, jeweils einen Anwendungsfall.

Dies nimmt den Fokus aus der Datenbank und verschiebt ihn zum Kern des Problems: den Geschäftsregeln. Wenn Sie mit der Implementierung der Geschäftsregeln beginnen, werden Sie schließlich (übrigens durch einen Prozess, der Natural Selection sehr ähnlich ist) feststellen, welche Daten vom Unternehmen wirklich benötigt werden. Wenn Sie mit der Modellierung der Datenbank beginnen, ohne die Rückmeldung zu erhalten, ob diese Daten wirklich benötigt werden (oder in diesem Format oder in diesem Normalisierungsgrad usw.), werden Sie entweder viele späte Anpassungen vornehmen das Schema (das möglicherweise umfangreiche Migrationsverfahren erfordert, wenn das Unternehmen bereits damit läuft), oder Sie müssen "Workarounds" in den Geschäftsregeln implementieren, um das verstimmte Datenmodell auszugleichen.

TL; DR: Die Datenbank hängt vom Unternehmen ab - sie wird von ihnen definiert. Sie benötigen die Daten nur, wenn Sie über einen Prozess verfügen, der damit arbeitet (ein Bericht ist auch ein Prozess). Implementieren Sie den Prozess zuerst und Sie werden feststellen, welche Daten benötigt werden. Modellieren Sie die Daten zuerst, und Sie können möglicherweise nur zählen, wie viele Annahmen beim ersten Modellieren falsch waren.

Ein wenig außerhalb des Themas, aber sehr wichtig: Der von mir beschriebene Workflow wird häufig zusammen mit sehr wichtigen Methoden wie "Das Einfachste, was möglicherweise funktionieren könnte", einer testgetriebenen Entwicklung und dem Fokus auf die Entkopplung Ihrer Architektur von den Details verwendet steh dir in den Weg (Hinweis: Datenbank). Über den letzten, dieser Vortrag fasst die Idee ziemlich gut zusammen.

85
MichelHenrich

Eine Ursachenanalyse legt nahe, dass es sich bei diesem Problem nicht um eine Methode handelt, sondern um das Fehlen einer Spezifikation. Ohne eins spielt es keine Rolle, was Sie zuerst schreiben - Sie werden es trotzdem wegwerfen.

Tun Sie sich selbst einen Gefallen und führen Sie einige grundlegende Systemanalysen durch - identifizieren Sie einige Benutzer auf verschiedenen Ebenen, erstellen Sie einen schnellen und schmutzigen Fragebogen, schalten Sie Ihre Maschine aus, holen Sie sich Kaffee und Kekse/Donuts (oder was auch immer die Räder schmiert) und gehen Sie dann zu Fragen Sie sie an ihren Schreibtischen, was sie tun und was sie wissen/aufzeichnen müssen, um ihre Arbeit zu erledigen, auch wenn es offensichtlich erscheint - fragen Sie immer noch. Machen Sie sich keine Sorgen darüber, wie wichtig sie sind. Wenn sie zu beschäftigt sind, treffen Sie eine Vereinbarung, um ein anderes Mal zurückzukehren, oder lassen Sie es bei ihnen.

Sobald Sie das haben, sollten Sie in der Lage sein, alles zu erstellen, von dem Sie glauben, dass es die besten Ergebnisse liefert, und auf den Rest der Spezifikation warten.

17
James Snell

Meine Erfahrung ist wie folgt :

  • In den meisten Projekten, an denen ich gearbeitet habe, haben wir zuerst die Datenbank entworfen.
  • Oft sind Daten bereits in Tabellenkalkulationen, Legacy-Datenbanken, Papier usw. vorhanden. Diese Daten geben Ihnen Hinweise zu den Tabellen, die Sie zum Speichern benötigen.
  • Oft wird ein Prozess bereits verwendet, jedoch manuell oder unter Verwendung mehrerer unterschiedlicher Tools, die nicht automatisiert sind, nicht zusammenarbeiten und/oder nicht den Standards entsprechen.
  • Sobald Sie ein ausgereiftes Datenbankmodell haben, können Sie mit dem Entwerfen von Prototypformularen, Fenstern usw. beginnen, die diese Datenbank lesen und in diese schreiben.
  • Wenn Sie fortfahren, sind einige Änderungen erforderlich, um den zunächst nicht in Betracht gezogenen Dingen Rechnung zu tragen.

Denken Sie auch daran :

  • Es ist keine One-App <-> One-Database-Welt mehr. Möglicherweise muss Ihre App Daten aus mehr als einer Datenbank lesen oder schreiben, oder Ihre Lösung umfasst mehr als eine App, die dieselbe Datenbank verwendet.

Fazit: Ich empfehle Ihnen, zuerst die Datenbank zu entwerfen.

12

Ich wollte zuerst Datenbank sagen, da ich viel Erfahrung mit großen Projekten habe und Sie wirklich ein solides Datenmodell benötigen, wenn viele Entwickler parallel arbeiten.

Aber dann habe ich ein bisschen mehr darüber nachgedacht und festgestellt, dass wir bei den erfolgreicheren Großprojekten wirklich "Anforderungen zuerst" waren.

Ein guter, genau spezifizierter Satz von Geschäftsanforderungen führt zu einem guten Satz von funktionalen Anforderungen. Wenn Sie gute funktionale Anforderungen haben, passen die Datenmodell- und Modulspezifikationen ohne großen Aufwand zusammen.

11
James Anderson

Da dies so flüssig/nicht spezifiziert erscheint, würde ich zuerst die Frontend-GUI erstellen - das klingt nach dem, was Sie benötigen, um Antworten, Unterstützung, Zeit und Feedback von den Stakeholdern zu erhalten, oder? Sie kümmern sich nicht um Ihre brillanten normalisierten Tabellen und Fremdschlüsseleinschränkungen und kaskadierenden Löschvorgänge. Aber eine coole GUI mit vielen glänzenden Farben - das ist erstklassig!

Verwenden Sie für die anfängliche "Datenbank" des Backends etwas extrem Einfaches, möglicherweise nur Schlüssel/Werte, die in einer Datei gespeichert sind. Ich bin mit MS Access nicht vertraut, weiß also nicht, was das "leichteste" Backend sein würde. (eine Tabelle mit Tabellenkalkulationen?) Was auch immer schnell und schmutzig ist, planen Sie, es wegzuwerfen.

Wenn Sie können, verwenden Sie ein lustiges Erscheinungsbild in der GUI, um zu verdeutlichen, dass es sich um einen Prototyp handelt. Wenn alles andere fehlschlägt, verwenden Sie Karteikarten.

Vielleicht sind Ihre Stakeholder DB-Experten - das war bei mir manchmal der Fall! - In diesem Fall führen Sie einige DB-Entwürfe durch.

8
user949300