ORM promuove la de-normalizzazione del database?

Doctrine e Propel utilizzano entrambe l'ereditarietà di tabelle singole e concrete per mappare le relazioni degli oggetti. Il primo vede tutti i possibili campi dell'albero delle classi mappati su una singola tabella, mentre il secondo mappa ogni classe su una tabella specifica, duplicando i campi comuni nella gerarchia dell'ereditarietà.

Mentre questo facilita l'apparato ORM, mi suggerisce una cattiva progettazione del database. Questi cattivi schemi di progettazione devono essere applicati su un database?

È impossibile dire se un determinato progetto di database non è corretto senza sapere cosa sta facendo l'applicazione, la forma dei dati, le aspettative sulle prestazioni e così via. Mentre la normalizzazione in generale (in una certa misura) è vista come una buona pratica, è abbastanza comune denormalizzare aree di database per motivi di prestazioni, così buone e cattive sono molto aperte alla discussione senza molti più dati di quante ne abbiano molte persone all'inizio.

Aggiungi i molti approcci che possono essere adottati per obiettare alle mappature relazionali e le cose diventano ancora più complesse poiché la "migliore" struttura del database dipenderà dal modello di oggetti specifico, dal livello di eredità e così via.

Adottando un approccio unico per tutte le dimensioni, le librerie di persistenza ORM produrranno quasi sempre una struttura di database non ottimale per una determinata situazione e useranno alcune cose che possono essere viste come cattive pratiche per quella data situazione .

Potresti certamente scrivere un ORM normalizzato, ma vedresti implicazioni di prestazioni abbastanza elevate poiché per ogni inserimento in una tabella principale è necessario scansionare le varie tabelle di ricerca per vedere se esistevano valori, se ottenessero le loro chiavi e se non lo facessero non eseguire gli inserti pertinenti.

(Quando lo fai a mano, puoi accorciarne un po 'come sai che li hai presentati con un menu a discesa contenente solo un valore valido, quindi non devi fare queste ricerche, puoi semplicemente usare la chiave felice che stia andando per essere valido, l'ORM non ha potuto assumere tale presupposto in quanto non controlla l'interfaccia utente.)

Ma quello che devi ricordare è che non mirano a ottimizzare le prestazioni del database o l'integrità dei dati, stanno ottimizzando per la velocità di sviluppo . Se la struttura specifica dei tuoi dati è importante per te, allora devi codificare manualmente il tuo oggetto / mappature RDBMS, o almeno fare una valutazione dettagliata di tutte le librerie disponibili e selezionare quella che soddisfa maggiormente le tue esigenze ( se ne esiste uno).

Fondamentalmente si riduce ai requisiti e al compromesso tra dati ben strutturati, prestazioni del database e velocità di sviluppo. Come con molti compromessi, non puoi scegliere tutti e tre.

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

Il modello di dati dovrebbe essere basato sulle regole aziendali dell'applicazione e delle esigenze di prestazione.

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

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

Quindi la mia risposta è: No, io non la penso così . Probabilmente è in realtà un altro modo per aggirare, un buon ORM incoraggia una buona progettazione del database, almeno per coloro che hanno poca esperienza.