Gute Daten Tier Dev & Design: Was sind die häufigsten schlechten Praktiken in Datenebene Entwicklung?

Question

Ich bin zur Erforschung der besten Praktiken (bei einem angemessen hohen Niveau) für Anwendungsdesign für hoch wartbare Systeme, die in minimaler Reibung Veränderung führen. Mit dem "Data Tiere" Ich mein Datenbank-Design, Objekt-Relation Mapper (ORM) und die allgemeinen Datenzugriffstechnologien.

Von Ihrer Erfahrungen, was haben Sie fanden die häufigsten Fehler und schlechte Praktiken sein, wenn es um Datenebene Entwicklung kommt und welche Maßnahmen haben Sie getroffen / anstelle setzen / oder kann empfehlen, die Datenebene zu einem besseren Ort zu machen zu sein aus Sicht eines Entwicklers?

Ein Beispiel Antwort umfassen kann: Was ist die häufigste Ursache für eine langsame, schlecht skalierbare und erweiterbare Datenebene? + Welche Maßnahmen ergriffen werden können (es im Design oder Refactoring sein) um dieses Problem zu heilen?

Ich suche nach Kriegsgeschichten hier und einiger realen Welt Beratung, dass ich in öffentlich zugänglichen Leitfäden und Muster aufbauen kann.

Answer 1

Magie.

habe ich Hibernate , die automatisch speichert und holt Objekte aus einer Datenbank verwendet. Es unterstützt auch träges Laden, so dass ein betreffendes Objekt nur aus der Datenbank abgerufen wird, wenn Sie danach fragen. Dies funktioniert in einigen magische Art und Weise verstehe ich nicht.

Das alles funktioniert gut, solange es funktioniert, aber wenn es bricht es unmöglich ist, sie aufzuspüren. Ich denke, dass wir ein Problem hatten, als wir Hibernate kombiniert mit AOP , dass irgendwie das Objekt war noch nicht von Hibernate initialisiert, wenn unser Code ausgeführt wurde. Dieses Problem war sehr schwer zu debuggen, weil Hibernate in so mysteriöser Weise funktionieren.

Answer 2

Object-Relational-Mapping ist eine schlechte Praxis. Damit meine ich, dass es dazu neigt, Datenschemata zu erzeugen, die nur lose als „relational“ bezeichnet werden kann, und so sie skalieren schlecht und schlechte Datenintegrität aufweisen.

Das ist, weil richtig relationales Schema durch den Prozess der Normalisierung gewesen sein, während die Ergebnisse der O-R Mapping sind in der Regel Objektklassen als Datenbanktabellen implementiert. Diese werden normalerweise nicht normalisiert worden sind, sondern stattdessen wurde für die unmittelbare Bequemlichkeit des OO-Entwickler konzipiert.

Natürlich in Fällen, in denen die persistenten Datenanforderungen minimal sind, ist dies unwichtig.

Allerdings habe ich einmal für eine Reederei gearbeitet, die durch die Übernahme von mehreren anderen Unternehmen gewachsen war, und hatte die Entwicklung eines integrierten Betriebssystem ausgelagert (die verschiedenen unternehmensspezifische Systeme zu ersetzen sie geerbt hatte) an ein Unternehmen eine OO verwenden Methodik, mit einem Datenschema von OR-Mapping erzeugt. Die Leistungsmerkmale des Systems wurden so schlecht entwickelt, und das Datenschema so komplex, dass die Reederei fiel es nach so etwas wie zwei Jahren Entwicklungszeit - bevor es sogar live gegangen

Dies war eine direkte Folge des O-R-Mapping; die schlechteste Komplexität im Schema (und die folglich eine schlechte Leistung) durch das Vorhandensein von Tabellen erstellt ausschließlich als Artefakte des OO-Design-Prozess verursacht wurde - sie reflektiert Bildschirmlayouts, nicht Datenbeziehungen

.