Was ist wichtiger? DB-Design oder Kodierung?

Question

Was ist wichtiger: Der Entwurf der Datenbank? Oder das Design des Anwendungscodes?

Es gibt eine Menge Informationen über wiederverwendbaren Code (von Carl Franklin bei dnrtv.de , CSLA.net et. al.), aber ich sehe nicht allzu viele Informationen über das Datenbankdesign und seine Auswirkungen auf die Lebensdauer einer Anwendung (insbesondere, wie sich schlechte Designentscheidungen in der Anfangsphase auf die Anwendung in ihrem späteren "Leben" auswirken).

Answer 1

Eine Datenbank ist ein Artefakt eines Computerprogramms, das einen bestimmten Prozess und ein System modelliert.

Im Idealfall sollte dies keine Rolle spielen.

Die derzeitige Technologie der Objektpersistenz ist noch nicht ganz ausgereift, so dass Sie sich wahrscheinlich noch einige Zeit damit beschäftigen werden.

Die Frage ist: Wozu ist die Datenbank da?

Wenn es dazu dient, die Objekte in Ihrem Modell der Prozesse und Systeme aufrechtzuerhalten, sollten Sie damit nicht viel zu tun haben.

Wenn es dazu da ist, Löcher in Ihrem Modell zu stopfen, werden Sie viel Zeit damit verbringen

Answer 2

IMHO ist ein gutes Datenbankdesign wichtiger als eine gute Kodierung (gute Kodierung ist auch wichtig, aber im Vergleich zum Datenbankdesign).

1. Ganz einfach, weil die Datenbank Ihre wertvollen Daten speichern wird.
2. Schlechte Kodierung wirkt sich zwar nicht auf die Datenbank, wohl aber auf die Skalierbarkeit, die Leistung der gesamten Anwendung usw. aus. Im Laufe der Zeit kann dies durch Refactoring behoben werden (was natürlich einige Kosten verursacht).
3. Das Refactoring einer Datenbank ist viel kostspieliger und schwieriger.
4. Außerdem haben wir normalerweise mehrere verschiedene Anwendungen auf derselben Datenbank laufen, so dass es ein gemeinsamer Faktor ist.

Answer 3

Vielleicht bin ich nicht sehr erfahren im Datenbankdesign, aber mein Gefühl ist: wenn Ihre Geschäftsklassen gut entworfen sind, ist der einzige Punkt, an dem Sie auf die Datenbank zugreifen, in Ihren Repositories (DDD gesprochen).

Eine Änderung in der Datenbank ist also nur eine Änderung in der Implementierung Ihres Repositorys. Ein schlechtes Datenbankdesign macht Ihr Repository schwer zu programmieren und langsam in der Ausführung, aber es hat keine Auswirkungen auf Ihre Geschäftsschicht (90 % Ihres Codes).

Wenn Sie versuchen, Ihre Geschäftsschicht wegen Ihrer DAO-Schicht zu ändern, warum dann nicht auch Ihre Geschäftsschicht wegen Ihrer Präsentationsschicht? und dann viel Glück, um alle Zwänge und guten Praktiken zu erfüllen!

Ich denke, dass beides wichtig ist, aber die Programmierung und das Datenbankdesign sollten nicht in denselben Händen liegen. Für den Entwickler ist es wichtiger, sich von der Arbeit des Datenbankdesigners zu isolieren (selbst wenn der Datenbankdesigner und der Entwickler dieselbe Person sind, sollte man nicht an zwei Dinge gleichzeitig denken müssen).

Answer 4

Es kommt natürlich darauf an, was Ihnen Spaß macht, aber die Zukunft liegt in der Abstraktion der Datenschicht, d. h. in der Betrachtung des Datenspeichers als ein Implementierungsdetail und nicht als Kern der Anwendung.

In bestimmten Kreisen hört man den Begriff "Persistenz-Ignoranz". Das Ziel ist, dass das Domänenmodell (Geschäftseinheiten) entworfen wird, ohne zu wissen, wie die Daten gespeichert werden. Hinter den Kulissen können sie in SQL, AmazonDB oder XML gespeichert sein.

Wenn Sie Spaß an DBA-Kram haben, sind Sie hier genau richtig. Wenn Sie aber eher auf der Anwendungsseite tätig sein wollen, sollten Sie sich mit ORM-Frameworks vertraut machen.

Answer 5

Entwerfen Sie, wenn Sie ein DBM sind.

Kodierung, wenn Sie Programmierer sind.

Diese schließen sich nicht gegenseitig aus und sollten beide gut ausgeführt werden.