ORM è uno strumento non valido per le strutture DB ad albero?

Question

ORM è uno strumento non valido per le strutture DB ad albero?

#1 da (9 voti)
#2 da (7 voti)
#3 da (5 voti)

8

So che questa domanda potrebbe essere chiusa come basata sull'opinione pubblica, ma ciò di cui ho bisogno in questo momento sono alcune opinioni supportate da argomenti.

Sto costruendo un'applicazione con Postgres ed Ecto (Elixir) come livello di persistenza. C'è un'entità che si riferisce a se stessa in modo che tu possa costruire una struttura ad albero con essa. Più sto cercando di farlo con Ecto, più mi sento frustrato.

Gli ORM sono semplicemente un cattivo strumento per la creazione di strutture DB complesse con molte associazioni? Il modo orientato agli oggetti che ORM tenta di applicare sui dati relazionali sembra essere un approccio negativo qui. Gli oggetti sono isolati Se interagiscono con altri oggetti, devono (dovrebbero) inviare messaggi. I loro dettagli interni dovrebbero rimanere nascosti. I dati relazionali formano un grafico aperto e trasparente. Questi due mondi sembrano essere completamente incompatibili con me.

Tuttavia, gli ORM sono molto comuni e popolari. La maggior parte delle applicazioni web funziona con entità piuttosto isolate che funzionano bene con ORM, o perché è così? Mi sembra che se volessi implementare un modello ERD mediamente complesso usando un framework ORM, devi sacrificare codice o prestazioni concise.

relational-database orm

posta Adam Libuša 09.03.2017 - 15:22

fonte

3 risposte

Leggi altre domande sui tag relational-database orm

Dipendenza ciclica con la classe logger e filesystem Quali tratti hanno in comune i migliori tester con cui hai lavorato?

score 9 · Answer 1

Alla fine della giornata un ORM è solo un'astrazione che genera sql per te e associa i dati ai tuoi oggetti. Salvataggio (tm) di un codice 'boiler plate'.

Quindi non c'è nulla che gli ORM nel loro insieme siano necessariamente cattivi per definizione. Il problema è che non usi gli ORM nel loro insieme, devi sceglierne uno specifico e usarlo!

Un singolo ORM può benissimo non fare una cosa particolare molto bene. Processi memorizzati, sql dinamico, campi calcolati, join complicati ecc. Possono essere aree problematiche.

Un problema più sottile è che come un ORM tenta di gestire tutti questi scenari in modo generico diventa più grande e più complicato da usare.

Se hai un'applicazione di grandi dimensioni o complicata, è probabile che a un certo punto si verifichi un problema con l'ORM che hai scelto. Quindi ha senso pianificarlo in anticipo e assicurarsi di nascondere l'ORM dietro un repository. In questo modo sei libero di sostituirlo con un'alternativa, o tornare a codificare SQL a mano, se necessario.

score 7 · Answer 2

Are ORMs simply a bad tool for creating complex DB-structures with many associations?

No. Ad esempio, Ruby on Rails utilizza ActiveRecord, che gestisce le associazioni. Nell'esempio qui: link , l'albero- come la struttura è realizzata con 2 linee di codice.

Quindi direi che è molto più facile che provare a pubblicare le tue query SQL.

Does majority of web applications work with rather isolated entities that play well with ORM, or why is that?

Probabilmente no, ma è solo una congettura. Gli ORM esistono in un ecosistema in cui prosperano, suggerendo che vengano utilizzati. Ho usato gli ORM per i sistemi con oltre 20 modelli associati e li ho trovati adatti. Non ho mai forzato l'isolamento degli oggetti con il solo passaggio dei messaggi.

Come opinione sommaria, se stai realizzando modelli ERD "complessi", non esiste uno strumento che li renda più facili. Solo strumenti che li fanno funzionare.

score 5 · Answer 3

Come notato in almeno un'altra risposta qui, tutti gli ORM non sono la stessa cosa. Alcuni ORM fanno ipotesi molto significative su come il database dovrebbe essere strutturato. Gli strumenti dovrebbero fornire un certo supporto per uscire da questo modello, ma più vai fuori da quel modello, meno valore ha l'ORM. Se si lavora con uno strumento ORM più prepotente, si avrà un'esperienza molto migliore se si progetta il database attorno alle sue ipotesi implicite.

Non ho mai veramente capito perché gli ORM siano visti da molti sviluppatori e architetti come essenziali. Ciò potrebbe essere dovuto al fatto che non ho quasi mai avuto un database di campo verde con cui lavorare e il tempo e gli sforzi necessari per ottenere la mappatura ORM sono stati molto più utili rispetto alla scrittura dell'SQL. O la mappatura era semplice (e lo era anche l'SQL) oppure era complicata e avevo bisogno di SQL (o qualcosa di simile) comunque. Il "supporto" transazionale incluso in ORM è stato più una fonte di bug e problemi di un aiuto, nella mia esperienza.

La tua situazione potrebbe variare, ma sono giunto alla conclusione che è meglio pensare alla persistenza del database come a un caso speciale di serializzazione dei dati. E come penso che non abbia senso credere di poter "mandare" un oggetto sul filo, non penso che abbia davvero senso pensare di scrivere oggetti in un database. Penso addirittura che sia completamente valido avere rappresentazioni multiple di oggetti degli stessi dati per esigenze diverse. Mappare gli oggetti alle tabelle e viceversa è diventato un fine a se stesso in contrasto con una soluzione a un problema. Non sono convinto che la maggior parte delle persone che usano questi strumenti abbia anche una chiara ragione per volere farlo. È diventato predefinito.