Quando utilizzare un ORM (Sequel, Datamapper, AR, ecc.) Rispetto a puro SQL per query

Question

Un mio collega sta attualmente progettando query SQL come quella seguente per produrre report, che vengono visualizzati nei file excel tramite un esterno query di dati. Al momento sono richiesti solo processi di reporting sul DB (nessuna operazione CRUD).

Sto cercando di convincerlo che sarebbe meglio usare un rubino ORM per poter visualizzare i dati in un'app rotaie/sinatra.

Nonostante gli evidenti vantaggi nella visualizzazione dei dati, quali vantaggi ci sono per lui nell'imparare a utilizzare un ORM come Sequel o Datamapper?

Le query SQL che sta scrivendo sono chiaramente piuttosto complesse e, essendo relativamente nuovo per SQL, si lamenta spesso che è molto dispendioso in termini di tempo e confusione. È possibile scrivere query estremamente complesse con un ORM? e se sì, qual è il più adatto (ho sentito che Sequel è buono per i dbs legacy)? e quali sono i vantaggi dell'apprendimento di ruby ​​e dell'utilizzo di un ORM rispetto al semplice SQL, nella creazione di query di database complesse?

Answer 1

Sono il manutentore di DataMapper e penso che per i report complessi si debba usare SQL.

Mentre penso che un giorno avremo un DSL che fornisce la potenza e la concisione di SQL, tutto ciò che ho visto finora richiede di scrivere più codice Ruby di SQL per query complesse. Preferirei piuttosto mantenere una query SQL a 5 righe di 10-15 righe di codice Ruby per descrivere la stessa operazione complessa.

Nota che dico complesso .. se hai qualcosa di semplice, usa i cercatori incorporati dell'ORM. Tuttavia, credo che ci sia una linea che puoi attraversare dove SQL diventa più semplice. Ora, la maggior parte delle app non sta solo riportando. Potresti avere molte operazioni di tipo CRUD, per le quali un ORM è perfettamente adatto e molto meglio che fare queste cose a mano.

Una cosa che di solito un ORM fornisce è una sorta di organizzazione della logica dell'applicazione. È possibile raggruppare il codice basato su ciascun modello nello stesso file. Di solito è lì che metterò la query SQL complessa, piuttosto che incorporarlo nel controller, ad esempio:

class User 
    include DataMapper::Resource 

    property :id, Serial 
    property :name, String, :length => 1..100, :required => true 
    property :age, Integer, :min => 1, :max => 130 

    def self.some_complex_query 
    repository.adapter.select <<-SQL 
     SELECT ... 
     FROM ... 
     WHERE ... 
     ... more complex stuff here ... 
    SQL 
    end 
end 

allora posso solo generare il report utilizzando User.some_complex_query. È anche possibile inserire la query SQL in una vista se si desidera eseguire ulteriormente la pulizia di questo codice.

MODIFICA: Per "vista" nella frase precedente intendevo la vista RDBMS, piuttosto che la vista nel contesto MVC. Volevo solo chiarire qualsiasi potenziale confusione.

Answer 2

ORM acronimo di Object Relational Mapping - ma guardando la query tuo amico sembra essere che vogliono una bella tabella specifica di somme e altri oggetti ... non ho usato Sequel di Ruby, ma ho usato Hibernate, e Python's SQLAlchemy (per Django/Turbogears) e mentre tu puoi fare questo tipo di domande, non credo che sia la loro forza.

Il potere di ORM deriva dall'essere in grado di trovare relazioni tra oggetti Foo->, diciamo che vuoi tutti gli oggetti Bar per il campo di Foo maggiore di X ... Quel genere di cose. Quindi non classificherei un ORM come una soluzione "buona", anche se passando ad un vero linguaggio di programmazione come Ruby e facendo lo SQL attraverso di esso invece di Excel ... che di per sé è una vittoria.

Solo i miei 2 centesimi.

Answer 3

Se si scrivono le query manualmente, è possibile ottimizzarle. Quando guardo quella query, vedo alcune potenzialità di ottimizzazione (E.ICGROUPNAME LIKE '% san-fransisco%' o E.ICGROUPNAME LIKE '% bordeaux%' non usa un indice = Tabella Scan).

Quando si utilizza un OR Mapper (gli oggetti/tabelle nativi) per i report si ha un controllo minimo o nullo sulla query SQL risultante.

Tuttavia: è possibile inserire tale query in una vista o in una stored procedure e mappare tale vista/Proc con un mappatore OR. È possibile ottimizzare le query e è possibile utilizzare tutte le funzionalità del framework dell'applicazione.

Answer 4

In una situazione del genere, avrei probabilmente li scrivo a mano o utilizzare una visualizzazione (se il DB si sta utilizzando supporti visualizzazioni)

Answer 5

A meno che non hai a che fare con gli oggetti, un ORM non è necessaria . Sembra che il tuo amico abbia semplicemente bisogno di generare report, nel qual caso SQL puro va bene finché sa cosa sta facendo (ad esempio evitando problemi di SQL injection).

ORM sta per "Mappatura relazionale oggetto". Se non hai la "O" (oggetti), probabilmente non è adatto alla tua app. Dove gli ORM brillano davvero è in oggetti persistenti per il database e li carica da un database.

Answer 6

Gli ORM vengono utilizzati quando si dispone di oggetti (oggetti business). Pertanto, presumo che tu abbia un'applicazione con la quale stai creando e gestendo i Business Objects che vengono infine salvati nel database. Se hai, allora hai quasi sicuramente una rappresentazione delle relazioni e probabilmente molti dei calcoli che utilizzerai nei rapporti. Il problema con l'utilizzo di SQL per accedere direttamente al database per i report è semplicemente la manutenibilità. Di solito ci si adopera per garantire che i propri oggetti aziendali nascondano i dettagli del proprio database. Implementa le regole aziendali e esegui calcoli comuni nei tuoi oggetti aziendali. Costruisci un linguaggio comune per tutti i membri del team ecc. Quindi usi un ORM per mappare il database e usa Habanero o NHibernate o qualcosa del genere per fare ciò. Questo è tutto fantastico. Facciamo tutto questo nel nome della manutenibilità ed è grandioso. Puoi migrare la tua applicazione modificando il tuo design ecc. Ecc.

Ora vai e scrivi SQL per eseguire rapporti nel tempo in cui hai centinaia di rapporti. In primo luogo, spesso duplicano la logica che hai già nei tuoi BusinessObjects (di solito senza alcun test) e ancora peggio Bham Damb, scusate la manutenibilità ora è farcita dimentica di spostare un campo da un tavolo all'altro dimentica di dividere quel tavolo in due cambiando quel rapporto ecc. avere un numero di rapporti che si interrompono in modo imprevisto.

Il problema con la ricerca dei Domain Objects/Business Objects è semplicemente una delle prestazioni.

In sintesi, se si utilizzano concetti di progettazione guidata dal dominio o oggetto business, provare a utilizzarli per i report. (Probabilmente si eseguirà direttamente dal DB utilizzando SQL o stored proc per motivi di prestazioni, ma si provi a limitare a utilizzare prima i Business Objects e quindi utilizzare SQL). L'altra opzione, naturalmente, è l'utilizzo di un database di report separato (come alcuni concetti di BI) La mappatura dal DB transazionale al DB di report è quindi in un unico posto e facilmente modificabile nei casi in cui si desidera modificare il progetto.

Domain Objects (Business Objects) e ORM hanno tutte le conoscenze per consentire di iniziare a creare query ad alte prestazioni che vengono eseguite direttamente sul database mentre si utilizza la terminologia del dominio. Speriamo che questi continuino ad evolversi fino al punto in cui questa è una realtà.

Fino ad allora, se si utilizza Business Objects nell'applicazione provare usarli per Reporting quando le prestazioni sono un resort problema a SQL.