Code zuerst vs. Datenbank zuerst

77

Wenn ich die Software entwerfe und erstelle, an der ich arbeite, entwerfe und erstelle ich normalerweise zuerst die Back-End-SQL-Tabellen und fahre dann mit der eigentlichen Programmierung fort. Das Projekt, an dem ich gerade arbeite, hat mich allerdings ziemlich verwirrt. Dies liegt wahrscheinlich an einem Mangel an guten, soliden Voraussetzungen, aber diesmal kann ich leider wenig dagegen tun. Es ist eine Art "Just go make it happen" Situation, aber ich schweife ab.

Ich denke daran, meinen Workflow auf den Kopf zu stellen und zuerst die UI- und Datenmodellklassen zu erstellen, in der Hoffnung, dass mir durch das Herausarbeiten klar wird, wie mein Datenbankschema letztendlich aussehen wird. Ist das eine gute Idee? Ich bin nervös, dass ich eine Benutzeroberfläche bekomme 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 schlecht.)

Badeente
quelle
6
@gnat: Das ist ganz anders.
Robert Harvey
1
Wenn dies als Duplikat geschlossen wird, sollte es ein Duplikat dieser Frage sein . Die Antworten und Fragen stimmen eher mit meinen Fragen überein.
RubberDuck
1
@Mawg es ist ein Arbeitsprojekt. Ich habe mich so weit wie möglich zurückgedrängt, um die Anforderungen zu erfüllen. Daran muss gearbeitet werden, und ich kann nichts mehr dagegen tun.
Rubberduck
4
Ähm, neuer Job? Ich weiß, dass ich würde. Aber als 30-jähriger Freiberufler finde ich es einfach, wegzugehen, bevor es den Fan wirklich trifft (manche Leute können dir einfach nicht helfen), aber mir ist klar, dass es nicht für alle so einfach ist. Bleib, wenn du musst (kein vergleichbarer Arbeitgeber) in der Gegend, etc.), aber bleiben Sie nicht, wenn es beginnt, Sie zu beeinflussen.
Mawg

Antworten:

85

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

Zum Beispiel können Sie Ihr Datenmodell schrittweise aufbauen, indem Sie jeweils einen einzelnen Anwendungsfall mit nur speicherinterner Persistenz implementieren (oder alles, was so einfach zu implementieren ist). Wenn Sie der Meinung sind, dass Sie genügend Anwendungsfälle implementiert haben, um die grundlegenden Entitäten zu skizzieren, können Sie die speicherinterne Persistenz durch eine echte Datenbank ersetzen und dann das Schema bei jedem weiteren Anwendungsfall weiter verfeinern.

Dadurch wird der Fokus aus der Datenbank entfernt und zum Kern des Problems verschoben: den Geschäftsregeln. Wenn Sie mit der Implementierung der Geschäftsregeln beginnen, werden Sie schließlich feststellen (durch einen Prozess, der im Übrigen Natural Selection sehr ähnlich ist), welche Daten vom Unternehmen wirklich benötigt werden. Wenn Sie mit der Modellierung der Datenbank beginnen und nicht wissen, ob diese Daten wirklich benötigt werden (oder in diesem Format oder in diesem Normalisierungsgrad usw.), werden Sie am Ende entweder eine Menge später Anpassungen vornehmen das Schema (das möglicherweise umfangreiche Migrationsvorgänge erfordert, wenn das Unternehmen bereits damit arbeitet), oder Sie müssen "Workarounds" in den Geschäftsregeln implementieren, um das gestörte Datenmodell auszugleichen.

TL; DR: Die Datenbank hängt vom Geschäft 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 zuerst den Prozess und Sie werden feststellen, welche Daten benötigt werden. Modellieren Sie zuerst die Daten, 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 funktioniert", testgetriebener Entwicklung und dem Fokus, Ihre Architektur von den Details zu entkoppeln, verwendet sich in den Weg stellen (Hinweis: Datenbank). Über den letzten, fasst dieser Vortrag die Idee ziemlich gut zusammen.

MichelHenrich
quelle
1
"Die Datenbank ist ein Detail". Vielen Dank für den Link. Ich bin von ganzem Herzen davon überzeugt, dass ich in der Lage sein werde, das Verlassen der Datenbank als verzögerte Entscheidung anzugehen, nachdem ich diesen Vortrag gesehen habe.
RubberDuck
6
Und nur einen Namen auf sie setzen: Diese Praktiken sind alle (wohl die ) wichtige Praktiken in Agile Entwicklung (inkrementelle Entwicklung, die einfachste Sache , die funktionieren könnte, Test-Driven, Benutzer muss zuerst ...).
sleske
8
Ich wollte zurückkommen und mich noch einmal bedanken. Ich habe meine gesamte mittlere Schicht ohne Datenbank und ich habe jetzt einen guten Überblick darüber, wie die Daten beibehalten werden sollten. Ich kann dir nicht genug danken. Ich würde noch einmal abstimmen, wenn ich könnte.
RubberDuck
12
Wenn Sie wirklich alle Anforderungen mit Ihrer Code-First-Methode erfassen und alle diese Anforderungen wirklich in Ihrer endgültigen Datenbank ausdrücken , kann ich dieser Antwort zustimmen. Aber ich habe viele, viele Projekte gesehen, bei denen die Zufriedenheit, etwas "zum Laufen zu bringen", zu der Einstellung führt, dass "wenn es funktioniert, die Datenbank gut genug sein muss", auch wenn es sich um ein SCHRECKLICHES Datenbankdesign mit unvermeidlichen und schwerwiegenden Leistungsproblemen handelt später. Außerdem scheinen viele Leute zu denken, dass der Code Daten validiert, für die Sie keine CHECK- oder FOREIGN KEY-Einschränkungen benötigen. Das tust du .
Ross Presser
2
Möglicherweise wird dies im Video behandelt - leider komme ich gerade nicht dazu -, aber ein weiterer Vorteil des inkrementellen Ansatzes ist, dass es bei richtiger Ausführung hilft, vage Spezifikationen zu verfestigen. "Sieht dieser Bildschirm so aus, als würde er alle benötigten Kontaktinformationen erfassen? Sind die Felder in einer Reihenfolge angeordnet, die für Ihren Workflow sinnvoll ist?" Diese Fragen stellen zu können - mit etwas Konkretem als Referenz - ist häufig die einzige Möglichkeit, die benötigten Informationen zu erhalten.
David
17

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

Tun Sie sich selbst einen Gefallen und führen Sie grundlegende Systemanalysen durch - identifizieren Sie einige Benutzer auf verschiedenen Ebenen, stellen Sie einen schnellen und schmutzigen Fragebogen zusammen, schalten Sie die Maschine aus, holen Sie sich Kaffee und Kekse / Donuts (oder was auch immer die Räder schmiert) und gehen Sie zu Fragen Sie ihre Schreibtische, 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 es bei ihnen zu lassen.

Sobald Sie das haben, sollten Sie in der Lage sein, mit dem Bauen zu beginnen, von dem Sie glauben, dass es die besten Ergebnisse bringt, und warten, bis der Rest der Spezifikation eingeht.

James Snell
quelle
Ich stimme voll und ganz zu, aber das wird in diesem Fall nicht passieren. Vielen Dank für Ihre Zeit.
RubberDuck
9
Wenn Sie keine Zeit haben, es richtig zu machen, wo werden Sie Zeit finden, es noch einmal zu machen?
Walter Mitty
Wer hat gesagt, dass man es nicht richtig macht @WalterMitty? Bitte beachten Sie den Videolink in der akzeptierten Antwort. Die Datenbank ist ein Detail , das nicht vorhanden sein muss, um die Fehler in 95% der Software zu beheben.
RubberDuck
1
Ich nahm an, dass "das wird nicht passieren" bedeutet, dass Sie mit dem Code fortfahren werden, ohne auch nur einen Hinweis darauf zu haben, welche Informationen die Stakeholder vom System benötigen. Ich denke, James hat Ihnen sehr gute Ratschläge gegeben, wie Sie eine grundlegende Systemanalyse durchführen können, ohne sich in eine Analyse-Lähmung zu verstricken.
Walter Mitty
Du hast mich bei WalterMitty falsch verstanden. Ich habe einen Feedback-Loop-Ansatz gewählt. Ich baue, was ich denke (ohne Datenbank) und bringe es dann zu den Benutzern. Ändern Sie das Programm. Wiederholen. Nach ein paar Iterationen sollte ich genau wissen, wie die Datenbank aussehen wird. Soweit ich weiß, ist der agile Ansatz speziell darauf ausgelegt, unklare Anforderungen zu bewältigen. Es ist in mir gut auf dieses Projekt zu sehen.
RubberDuck
12

Meine Erfahrung ist wie folgt:

  • In den meisten Projekten, an denen ich gearbeitet habe, haben wir zuerst die Datenbank entworfen.
  • Häufig sind Daten bereits in Tabellenkalkulationen, älteren Datenbanken, auf 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 mithilfe mehrerer unterschiedlicher Tools, die nicht automatisiert sind, nicht miteinander interagieren und / oder nicht den Standards entsprechen.
  • Sobald Sie ein halb ausgereiftes Datenbankmodell haben, können Sie mit dem Entwerfen von Prototypformularen, Fenstern usw. beginnen, die diese Datenbank lesen und in sie schreiben.
  • Im weiteren Verlauf sind einige Änderungen erforderlich, um den zunächst nicht in Betracht gezogenen Problemen 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 besteht aus mehr als einer App, die dieselbe Datenbank verwendet.

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

Tulains Córdova
quelle
Das sind alles sehr wahre Dinge, und in der Tat wird dies ein "Nicht-Prozess" und eine Kalkulationstabelle ersetzen, aber ich verstehe nicht, wie dies eine Antwort auf meine Frage ist. Können Sie bitte klarstellen?
RubberDuck
1
@RubberDuck Am Ende meiner Antwort habe ich eine Erläuterung hinzugefügt.
Tulains Córdova
11

Ich wollte Database First 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 das, was wir bei den erfolgreicheren Großprojekten wirklich machten, "Anforderungen zuerst" waren.

Ein gut spezifizierter Satz von Geschäftsanforderungen führt zu einem guten Satz von funktionalen Anforderungen. Wenn Sie gute funktionale Anforderungen haben, lassen sich die Datenmodell- und Modulspezifikationen einfach ohne großen Aufwand einfügen.

James Anderson
quelle
Genau so arbeite ich normalerweise. Voraussetzungen zuerst , ja. Wie ich wünschte, ich könnte jetzt einige solide Anforderungen aus jemandem herausziehen.
RubberDuck
Anforderungen zuerst, obwohl Sie nicht warten sollten, bis die Anforderungen vollständig sind (dies wird niemals der Fall sein). Machen Sie sich auf den Weg, sobald Sie eine Vorstellung von den Zielen der Anwendung haben, und holen Sie sich mehr, wenn Sie sie brauchen.
Sleske
@sleske - Ein guter Analyst sollte ein Gefühl für die "dynamischeren" (dh vagen und veränderlichen) Teile der Anforderungen bekommen und eine gewisse Flexibilität in das Design einbauen, um mit den Launen der Benutzer leicht fertig zu werden.
James Anderson
1
@JamesAnderson: Eigentlich bin ich ein großer Fan agiler Entwicklungsprinzipien, bei denen Sie normalerweise nur für das entwerfen, was Sie jetzt brauchen , es sei denn, Sie wissen, dass Sie das Design später nicht ändern können (selten der Fall). Aber ich fange an, vom Thema
abzuweichen
8

Da dies so flüssig / unspezifisch 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, Fremdschlüsselbeschränkungen und kaskadierenden Löschvorgänge. Aber eine coole Benutzeroberfläche mit vielen glänzenden Farben - das ist erstklassig!

Verwenden Sie für die anfängliche "Datenbank" des Backends etwas sehr 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 wäre. Was auch immer schnell und schmutzig ist, wirf es weg.

Wenn Sie können, verwenden Sie ein lustiges Aussehen und Verhalten 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.

user949300
quelle
3
+1 für weder "Code First" noch "Database First", sondern "Non Functional Gui-Prototype First" (auch bekannt als "Rapid Prototyping"), da der GUI-Prototyp bei fehlenden Anforderungen hilft, die Anforderungen mit den Endbenutzern zu klären.
k3b
1
Stimmt, aber es lässt sie auch glauben, dass die App so gut wie fertig ist. Ich wurde bereits so verbrannt und fordere jetzt, dass wir die Anforderungen zuerst
richtig stellen
@Mawg ja, das ist leider eine gefahr. Eine Möglichkeit (zumindest in Java) ist die Verwendung eines seltsamen "Look and Feel", um zu verdeutlichen, dass es sich um einen Prototyp handelt.
user949300
Wenn Sie nicht wissen, wohin Sie wollen, gelangen Sie mit jedem Code dorthin.
-1

Da die Anforderungen nicht klar sind, kann man mit einem sehr rudimentären Datenmodell mit den Schlüsselelementen beginnen, von denen Sie wissen, dass Sie sie benötigen, möglicherweise nur mit einfachen Tabellen und PKs. Den Rest der Daten serialisieren Sie in binär oder XML und speichern Sie das BLOB zunächst in der Datenbank. Das sollte es einem ermöglichen, die Benutzeroberfläche und die Business-Schicht (Middle Tier) ohne ein vollständig relationales Modell zu entwickeln, aber Sie werden weiterhin die Möglichkeit haben, Schlüssel nach Bedarf zu speichern und abzurufen und sie einfach nachzuschlagen.

Als Beispiel haben Sie vielleicht eine Person, also eine PK mit einer Personen-ID. Die restlichen Attribute sind nicht bekannt. Beginnen Sie also mit einer Personentabelle mit einer PK-Personen-ID und einer weiteren Spalte, in der das Blob mit allen Personendaten gespeichert wird.

Sobald sich die Anforderungen verfestigt haben, nehmen Sie Ihre Blobs, extrahieren Sie alle benötigten Tabellen und Spalten und machen Sie das Modell relational. Dann geht es nur darum, die Beständigkeit von einem BLOB in eine relationale in der Datenzugriffsschicht zu ändern. Aber alles andere, die Benutzeroberfläche für Geschäftsregeln usw. wird weiterhin funktionieren. Beachten Sie, dass dies dem Projekt etwas Zeit hinzufügt, aber die vollständige Flexibilität bietet, Dinge nach Bedarf hinzuzufügen und zu löschen, ohne das relationale Modell zu ändern, bis die Dinge fester werden

Die Suche kann sich verzögern, da Sie kein BLOB abfragen können. Wenn sich das Modell stabilisiert, speichern Sie die zu durchsuchenden Daten in relationalen Spalten.

Grundsätzlich beginnen Sie mit einem tabellarischen Modell und wechseln im Verlauf des Projekts zu einem relationalen Modell.

Oder legen Sie die Anforderungen fest, bevor Sie mit der Arbeit beginnen, damit zunächst ein relationales Modell entwickelt werden kann.

Jon Raynor
quelle
Auf diese Weise liegt der Wahnsinn. Behalten Sie niemals Daten bei, bis Sie bereit sind, die Daten beizubehalten. Das Normalisieren von Daten nachträglich ist ein Albtraum.
RubberDuck
1
Es gibt einen Unterschied zwischen Beharrlichkeit und Normalisierung. Die Frage, die nur Sie beantworten können, ist, ob ich nur beharren oder beharren und normalisieren muss. Ein Datenmodell ist ein Modell. Wenn es keine Anforderungen gibt, ist es schwierig, etwas relational zu modellieren.
Jon Raynor
-2

Im Allgemeinen denke ich, dass Code nach Daten kommt, weil der Code die Daten manipulieren wird.

Wenn die Anforderungen nicht klar sind, können Sie ein Datenmodell Ihrer Interpretation der Anforderungen erstellen. Am besten ist es, einige Anforderungen aufzuschreiben und an Ihren Arbeitgeber zu senden, dann haben sie etwas zu schießen. Oder erst eine GUI erstellen, es kommt auf die Art des Arbeitgebers an, was am besten funktioniert :)

Kein IhpleD
quelle
3
dies scheint nicht alles zu bieten erhebliche über Punkte gemacht und erläutert vor 5 Antworten
gnat
Mein Ziel ist es, je nach
Kundentyp