L'ORM promuove la de-normalizzazione del database?

È impossibile dire se un particolare design del database è cattivo senza sapere cosa sta facendo l'applicazione, la forma dei dati, le aspettative sulle prestazioni e così via. Mentre generalmente la normalizzazione (in una certa misura) è vista come best practice, è piuttosto comune denormalizzare le aree dei database per motivi di prestazioni, quindi i buoni ei cattivi sono molto aperti alla discussione senza molti più dati di quelli che la maggior parte delle persone ha quando iniziano. / p>

Aggiungi i molti approcci che possono essere adottati per opporsi ai mapping relazionali e le cose diventano ancora più complesse in quanto la "migliore" struttura del database dipenderà dal modello di oggetto specifico, dal livello di ereditarietà e così via.

Assumendo un unico approccio per tutte le librerie di persistenza ORM produrrà quasi sempre una struttura di database non ottimale per una data situazione e userà alcune cose che possono essere viste come cattive pratiche per quella determinata situazione .

Potresti sicuramente scrivere un ORM che si normalizzasse, ma vedresti implicazioni di prestazioni abbastanza pesanti come per ogni inserto in una tabella principale di cui necessitava per analizzare le varie tabelle di look up per vedere se i valori esistevano, se ottenevano le loro chiavi e se non hanno eseguito gli inserti pertinenti.

(Quando lo fai a mano puoi scartare un po 'di questo come sai che li hai presentati con un menu a discesa contenente solo un valore valido in modo da non aver bisogno di fare questi lookup, puoi semplicemente usare il tasto happy che sarà valido, l'ORM non è in grado di assumere tale assunto in quanto non controlla l'interfaccia utente.)

Ma ciò che devi ricordare è che non mirano a ottimizzare le prestazioni del database o l'integrità dei dati, stanno ottimizzando la velocità di sviluppo . Se la struttura specifica dei tuoi dati è importante per te, allora hai bisogno di codificare a mano i tuoi mapping di oggetti / RDBMS, o per lo meno fare una valutazione dettagliata di tutte le librerie disponibili e selezionare quella che soddisfa maggiormente le tue esigenze ( se ne esiste uno.

In sostanza si tratta dei requisiti e del compromesso tra dati ben strutturati, prestazioni del database e velocità di sviluppo. Come per molti compromessi, non puoi sceglierne tutti e tre.

Non sono d'accordo sul fatto che ORM promuova la de-normalizzazione o la cattiva progettazione del database. In effetti, i database progettati peggiori che ho visto sono stati realizzati senza ORM. Semplificando le relazioni corrette basate sull'id di riga invece di creare una relazione basata sul valore di un campo casuale, piuttosto promuove una buona progettazione del database.

Probabilmente non promuove la normalizzazione, ma di nuovo un ORM in cui è facile creare tabelle / oggetti e relazioni che potrebbero essere visti per promuoverlo. Non c'è molto più lavoro in un ORM per creare una tabella "location" con gli indirizzi e collegare i dipendenti alla posizione invece di aggiungere l'indirizzo alla tabella dei dipendenti. Ma senza l'ORM, separare la posizione significa che ogni volta che si desidera accedere alla posizione, è necessario effettuare un join.

Quindi la mia risposta è: No, non la penso così . Forse è in realtà un altro modo, un buon ORM incoraggia un buon design del database, almeno per coloro che hanno poca esperienza.

Come regola generale, non modellare mai i dati per soddisfare le esigenze dello sviluppatore (puoi utilizzare Views o Sp per questo, ma non il modello dati).

Il modello di dati deve essere basato sulle regole aziendali dell'applicazione e sulle esigenze di prestazioni.