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

Sehen Sie es so

1. Änderung des Codes bedeutet Änderung des Codes
2. Wenn Sie die Datenbank ändern, müssen Sie wahrscheinlich auch den Code ändern.

Daher ist es wichtig, die Datenbank so früh wie möglich so stabil wie möglich zu machen.

Answer 2

Nachdem ich zuvor mit einem entsetzlichen Datenbankdesign gearbeitet habe, muss ich meinen Hut in den Ring des Datenbank- (oder Datenmodell- / ORM-) Designs werfen.

Setzen Sie sich mit einigen Personen zusammen, die sich in Ihrem Unternehmen/Kunden mit dem Problembereich auskennen, und bringen Sie alle erforderlichen Daten zu Papier, gruppieren Sie sie nach logischen Bereichen, und beginnen Sie dann mit der Erstellung eines Datenmodells, das Sie in Objekte, Datenbankschemata oder eine .xsd-Datei usw. umwandeln können. Jedes Datenelement hat einen Namen, einen Typ, vielleicht eine maximale Länge für Zeichenketten, oder es handelt sich um eine Menge, Liste oder Karte mit bestimmten Mindest- oder Höchstkapazitäten.

Ob Sie danach zuerst die Datenbank oder das OO-Modell entwerfen, bleibt Ihnen überlassen, aber zumindest haben Sie sich im Vorfeld um ein vernünftiges partitioniertes Modell bemüht.

In der Tat würde ich in einem MVC-Design das OO-Datenmodell (Klassen in Java/C#) als das Modell klassifizieren, das untrennbar mit dem Datenbankschema verbunden ist (natürlich mit zusätzlichen Transienten und Dienstmethoden). Ihr Controller - das "Coding" in Ihrer Frage - sollte eigentlich die Geschäftslogik unter Verwendung des Modells implementieren, das durch die Objekte dargestellt wird, die Sie über ein DAO/ORM aus der Datenbank extrahieren.

Answer 3

Das Domänenmodell sollte unabhängig von den Details der Persistenz-Implementierung sein (auch wenn die Technologie dem Modell einige Beschränkungen auferlegt). http://www.infoq.com/articles/ddd-in-practice

Sie sollten sich auf das Domänenmodell konzentrieren. Mit großartiger ORM-Technologie wie Winterschlaf / NHibernate die Datenbank wird nur ein Detail der Implementierung sein.

Bücher, die Sie lesen sollten, wenn Sie sich mit .NET-Webentwicklung beschäftigen:

1. ASP.NET MVC Framework Vorschau (nur 100 Seiten, die Ihnen den Einstieg erleichtern)
2. NHibernate in Aktion
3. Bereichsorientiertes Design und Entwicklung in der Praxis (nicht gelesen, aber ich werde es tun, und es ist kostenlos)
4. Refactoring: Verbesserung des Designs von bestehendem Code

Answer 4

Beides ist nicht unwichtig, aber...

Ein schlechtes Datenbankdesign kann das Schreiben guter Programme unmöglich machen. Außerdem kann man schlechten Code normalerweise umschreiben, aber wenn man viele Daten in der Datenbank hat, muss man mit den schlechten Entscheidungen leben, die in der Entwurfsphase getroffen wurden.

Answer 5

Meiner Erfahrung nach (und ich bin seit etwa 30 Jahren mit der Behebung von Datenbankproblemen befasst und habe mit Hunderten von verschiedenen Datenbanken zu tun gehabt) sind allzu viele Probleme mit der Leistung von Datenbanken auf die unangemessenen Versuche zurückzuführen, Code wiederzuverwenden. Funktionen sind viel langsamer als Inline-Code. Cursor, die eine gespeicherte Prozedur wiederverwenden, die einen Datensatz nach dem anderen einfügt, sind viel, viel, viel (Lichtjahre) langsamer als mengenbasierter Code. Die Wiederverwendung einer Prozedur, die das, was Sie brauchen, und zehn weitere Felder zurückgibt, ist eine Verschwendung von Server- und Netzwerkressourcen. Die Verwendung einer vorhandenen Ansicht, die mit zehn Tabellen verknüpft ist, wenn Sie nur Informationen aus drei Tabellen benötigen, ist eine Verschwendung von Serverressourcen. Die Wiederverwendung von Code in Datenbanken ist nicht annähernd so sinnvoll wie in anderen Bereichen. Das soll nicht heißen, dass Code nicht wiederverwendet werden sollte, wenn es nötig ist. Sie sollte nur nie Vorrang vor der Leistung haben. Datenbanken sind leider nicht gut für die Wiederverwendung von Code geeignet. Die meisten Datenbanken sind nicht objektorientiert, und objektorientiertes Denken beim Entwurf oder Zugriff auf sie führt oft zu einem schlechten Entwurf.

Bevor Sie überhaupt über die Wiederverwendung von Code nachdenken können, brauchen Sie ein grundsolides normalisiertes Datenbankdesign. Sie müssen sich Gedanken darüber machen, wie Sie Daten in die Datenbank extrahieren und einfügen wollen. Sie müssen sich Gedanken darüber machen, wie gut das funktionieren wird, wenn es erst einmal viele Benutzer und Datensätze gibt, denn die Neugestaltung einer grundlegenden Datenbankstruktur wird zu diesem Zeitpunkt oft zu teuer und zeitaufwändig. Es ist oft viel einfacher, den Anwendungscode zu überarbeiten als die grundlegende Datenbankstruktur, und viel zu oft wird das Refactoring der Datenbank nicht durchgeführt. Wenn Sie die Tabellenstruktur ändern, um von einer denormalisierten Tabelle zu einer Eltern-Kind-Struktur überzugehen, weil Sie feststellen, dass die aktuelle Struktur nicht Ihren Anforderungen entspricht, müssen Sie am Ende möglicherweise Hunderte oder sogar Tausende von Abfragen für diese Tabelle ändern. Aus diesem Grund ist es wichtig, viel Zeit auf das Datenbankdesign zu verwenden, da Sie später aus Zeit- und Kostengründen keine Gelegenheit mehr haben werden, es zu überarbeiten. Wenn Sie sich die Datenbank als das Fundament des Hauses und den Anwendungscode als die Struktur vorstellen, werden Sie verstehen, warum das so ist. Es ist viel schwieriger, das Fundament mit der darauf befindlichen Struktur zu ändern, als die Innenwände zu verschieben. Mit Datenbanken und den Anwendungen, die auf sie zugreifen, verhält es sich genauso.