Livello buoni dati Dev & Design: Quali sono le cattive pratiche comuni per lo sviluppo dei dati di livello?

Question

Attualmente sto ricercando le migliori pratiche (ad un livello ragionevolmente elevato) per la progettazione di applicazioni per sistemi altamente mantenibili che si traducono in attrito minimo al cambiamento. Con "Tier Data" Io disegno media di database, Object relazioni con mapper (ORM) e di accesso ai dati generali tecnologie.

dalle vostre esperienze, che cosa hai trovato di essere gli errori più comuni e le cattive pratiche, quando si tratta di sviluppo livello dati e quali misure avete preso / mettere in atto / o può consigliare per rendere il livello dati un posto migliore per essere dal punto di vista degli sviluppatori?

Un esempio risposta potrebbe includere: Qual è il più comuni cause di una lenta, poco scalabile ed estensibile livelli di dati? + Quali possono essere adottate misure (sia esso in progettazione o refactoring) per la cura di questo problema?

Cerco storie di guerra qui e un po 'di vera e propria consulenza mondo che posso costruire in documenti di orientamento disponibili al pubblico e campioni.

Answer 1

Magic.

Hibernate , che memorizza automaticamente e recupera gli oggetti da un database. Supporta anche lazy loading, in modo che un oggetto correlato viene recuperato solo dal database quando si chiedono. Questo funziona in qualche modo magico che non capiscono.

Il tutto funziona bene finché funziona, ma quando si rompe è impossibile rintracciarlo. Penso che abbiamo avuto un problema quando abbiamo combinato Hibernate con AOP , che in qualche modo l'oggetto era non ancora inizializzato da Hibernate quando è stato eseguito il nostro codice. Questo problema è stato molto difficile da scovare perché Hibernate funziona in modi misteriosi.

Answer 2

object-relational mapping è una cattiva pratica. Con questo, intendo che tende a produrre schemi di dati che può solo essere liberamente definite "relazionale", e così scalabili male e mostrano scarsa integrità dei dati.

Questo perché schemi correttamente relazionali sono passati attraverso il processo di normalizzazione, che i risultati di O-R Mapping sono normalmente classi di oggetti implementati come tabelle del database. Questi normalmente non sono stati normalizzati, ma sarà invece sono state progettate per la comodità immediata dello sviluppatore OO.

Naturalmente, nei casi in cui i requisiti di dati persistenti sono minime, questo non è importante.

Tuttavia, una volta ho lavorato per una compagnia di navigazione che era cresciuta rilevando diverse altre società, e aveva in outsourcing lo sviluppo di un sistema operativo integrato (per sostituire i vari sistemi aziendali specifici che aveva ereditato) ad una società che utilizza un OO metodologia, con uno schema di dati prodotta dalla mappatura O. Le caratteristiche di prestazione del sistema in fase di sviluppo sono stati così poveri, e lo schema di dati così complesso, che la compagnia di navigazione è sceso dopo qualcosa come due anni di sviluppo - prima ancora che è andato in diretta

Questa è stata una diretta conseguenza della mappatura O-R; la peggiore complessità nello schema (e il conseguente scarso rendimento) è stato causato dalla presenza di tabelle create esclusivamente come artefatti del processo di progettazione OO - hanno riflettuto layout dello schermo, non relazioni tra i dati

.