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

Ich sehe schon, dass ich stromaufwärts schwimmen werde, aber ich bin ziemlich stark davon überzeugt, dass Software die Antwort auf Ihre Frage ist.

Während sich Ihre Software an ein schwaches Schema anpassen kann, kann Ihnen Ihre Datenbank nicht viel helfen, wenn Ihre Software nicht funktioniert. Ich hatte schon einige Fälle, in denen ich eine beliebte Front-End-Anwendung komplett neu aufbauen konnte, ohne dass es zu ernsthaften Störungen kam, weil die Benutzer die Datenbank nicht direkt sehen. (Was nicht der Fall sein wird, wenn die Software Mist ist.)

Ich würde also sagen, dass man sich zuerst um die Dinge kümmern sollte, die dem Nutzer am nächsten sind.

Answer 2

Ich werde nicht versuchen, viele der bisher gemachten guten Kommentare zu wiederholen. Auch werde ich keine Zeit darauf verwenden, die ebenfalls gemachten zweifelhaften Aussagen zu identifizieren.

Ich möchte jedoch folgende Punkte hinzufügen.

Wenn Sie wie die meisten Menschen sind, beziehen Sie sich in Ihrer Frage auf ein RDBMS als Datenbank. Ein RDBMS ist im Wesentlichen ein Slave. Es lauscht an einem Port und ist verpflichtet, alle Anfragen zu bearbeiten, die über diesen Port eingehen. Es hat keine Möglichkeit zu wissen, welche dieser Anfragen einfach nur dumm oder unklug sind. Daher kann auch die perfekteste DB so missbraucht werden, dass sie den Server blockiert. Dies impliziert, dass der Code wichtiger ist. DBAs sind überall zu finden, wo sie sich die Haare raufen angesichts der dummen Dinge, die Anwendungsentwickler auf die von ihnen verwalteten Server werfen.

Der beste Rat, den ich Ihnen zu diesem Thema geben kann, ist also sicherzustellen, dass der Zugriff auf die DB über eine API erfolgt, die von demselben Entwickler geschrieben wurde, der auch die DB entworfen hat. Machen Sie es zur Aufgabe eines Mannes (oder einer Gruppe, die demselben Mann unterstellt ist), dafür zu sorgen, dass solide Designentscheidungen für beide getroffen werden. Wenn Sie dieser Typ sind, dann sparen Sie nicht an dem einen auf Kosten des anderen. Entwerfen Sie Ihre API so, dass ein Refactoring der DB für die Clients der API transparent durchgeführt werden kann.

Answer 3

In gewisser Weise kann man beides nicht trennen: DB-Design ist Kodierung - es ist nur keine Kodierung in einer prozeduralen Sprache.

Ich habe jedoch auch schon mit Systemen gearbeitet, die schlecht konzipierte prozedurale Software hatten, und ich habe mit Systemen gearbeitet, die schlecht konzipierte Datenbankschemata (Schemata?) hatten. Meiner Erfahrung nach ist es aufgrund von Upgrade- und Kompatibilitätsproblemen viel schwieriger, die Schemata zu reparieren. Ich kann mir Systeme vorstellen, bei denen dies nicht der Fall war.

Answer 4

Ich glaube nicht, dass man die beiden so trennen kann, wie Sie es beschreiben. Das eine beeinflusst unweigerlich das andere. Ein solides Datenbankdesign, das leicht zu pflegen ist und eine gute Leistung erbringt, bedeutet beispielsweise weniger Codeänderungen. Eine gute Code-Architektur und ein gutes Verständnis Ihrer Anwendungsfälle führen zu einem sauberen und wartbaren Datenbankschema.

Für mein Geld würde ich mehr für eine solide Geschäftsschicht ausgeben und meine Datenbank so aufbauen, dass sie diese unterstützt, aber das ist mein Wissensvorsprung.

Answer 5

Beide sind natürlich wichtig, es ist eine symbiotische Beziehung.

Aber wenn Ihre DB defekt ist, kann kein noch so guter Code Ihre Anwendung zum Strahlen bringen.

Wenn Ihre DB jedoch wirklich gut ist, kann guter Code sie noch besser machen (aber schlechter Code kann sie immer noch ruinieren).