Con così tanti strumenti ORM per la maggior parte dei linguaggi moderni, esiste ancora un caso d'uso per scrivere ed eseguire SQL in un programma, in un linguaggio / ambiente che li supporta? Se è così, perché?
Per maggiore chiarezza: non sto chiedendo se i programmatori debbano conoscere SQL o se dovrei avere uno strumento SQL sul mio desktop. Sto chiedendo specificamente perché potrei averlo nel codice (o config, o qualsiasi altra cosa) in opposizione a un ORM.
SELECT * FROM... , Dio uccide un gattino. E tu odio gattini. Gli ORM sono ottimi per le cose basilari. Tuttavia, per situazioni complesse, dovrai scrivere SQL.
Quindi, in breve, c'è sicuramente bisogno di SQL e rimarrà sempre così.
ORM non aiuta a costruire, ottimizzare o automatizzare il database. Ti dà solo un modo alternativo per interagire con il database una volta che hai fatto tutto questo.
Certo:
Gli ORM esistono a causa della mancata corrispondenza dell'impedenza tra le nostre comuni implementazioni DB relazionali e le nostre funzioni linguistiche OO. Sono solo un ponte, eppure la maggior parte della gente tratta SQL come il formaggio Limburger nel frigo.
Se si può legittimamente affermare che userete sempre il vostro ORM o altro livello di accesso ai dati astratti invece di trattare le procedure / viste SQL / memorizzate come un'interfaccia di prima classe, allora probabilmente stareste meglio senza toccare SQL.
In pratica, non ho mai visto un progetto ORM puro che non richiedesse almeno SQL per interrogare il database per la convalida finale.
Gli ORM sono uno strumento nella casella degli strumenti dei programmatori. Hanno i loro problemi. Alcuni esempi sono:
Se sai cosa stai facendo, puoi utilizzare efficacemente un ORM per sostituire gran parte del tuo codice di tipo CRUD. Non sono altrettanto efficaci per le cose complesse, ma sono difficili da sintonizzare sulle prestazioni (sai che le prestazioni sono una delle parti critiche del design del database, non emulano oggetti) e sono decisamente orribili e pericolose nelle mani di qualcuno che non capisco o scrive SQL da solo
Voglio anche sottolineare che la complessa reportistica non è facile da fare efficacemente con un ORM. Inoltre, se non si impara il semplice SQL nelle cose semplici e crude, come si arriva al punto in cui è possibile scrivere SQL complessi per i report? Non ho mai lavorato in un'applicazione che non aveva esigenze di reporting e spesso piuttosto complicate.
Né gli ORM sono utili per i processi BI o ETL per la maggior parte. Né sono utili per le query di amministrazione del database o per la ricerca di informazioni nelle tabelle di controllo e l'annullamento di un particolare insieme di modifiche al database. Ci sono molte molte cose che sono ancora più efficacemente eseguite con SQL. L'applicazione che interroga il database è una piccola parte di ciò che deve essere interrogato in un ambiente Enterprise.
Vedo anche molte domande su come fare qualcosa usando un ORM che il poster sa già come fare in SQL. È bello imparare cose nuove, ma quando stanno causando più tempo e sforzi senza alcun guadagno reale rispetto al metodo originale (e spesso una vera perdita di prestazioni), perché le stai usando in modo diverso da come sono "alla moda" in questo momento.
A volte un cliente vuole solo una query facile e veloce per restituire i dati per un report, esportare, datadump, ecc. e aspettare che venga sviluppato un intero programma.
Inoltre, un buon programmatore SQL può sempre scrivere SQL più veloce, più efficiente di qualsiasi ORM che ho usato. Inoltre, ho scoperto che molte persone hanno solo il punto ORM per le stored procedure, ignorando davvero i vantaggi dell'ORM, perché gli ORM non sono ideali per i processi complessi.
Inoltre, quando si utilizza un database come Oracle con un linguaggio procedurale molto ricco e potente, si può fare molto senza mai avere bisogno di un "programma". PL / SQL su Oracle nelle mani giuste è molto veloce ed efficiente.
Se vuoi usare un database tu stesso, sì. La maggior parte degli ORM che ho provato ad usare non erano sufficienti o non coprivano il mio database. Inoltre, come hai intenzione di risolvere o scrivere query personalizzate che non sono coperte?
È ancora necessario per scrivere trigger e stored procedure. Al momento le procedure memorizzate potrebbero non essere state gradite, ma in alcune situazioni sono comunque molto utili. SQL può anche essere richiesto per alcuni join multi-tabella particolarmente pelosi.
Sì, puoi evitare di scrivere SQL. Ma finirai per scrivere HQL (o Linq o DQL ...)!
Scherzi a parte, sono un grande fan degli ORM, e penso che si possa evitare di usare puro SQL per la maggior parte del tempo. Ma dobbiamo ricordare che un ORM è solo una grande astrazione e tutte le grandi astrazioni perdita ...
(Ma riguardo al problema N + 1: si tratta di un caricamento lazy correlato e la maggior parte degli strumenti ORM ha un qualche modo per richiedere il caricamento con entusiasmo, evitando così quel particolare problema.)
ORM ti porterà solo ad un certo punto. Ma ci sono casi in cui devi eseguire una query davvero complicata, con join complicati, sottoquery, unioni, meno, funzioni analitiche ecc. Ecco quando hai bisogno di SQL. Ma come dovresti scrivere query complicate quando lasci tutte le query semplici all'ORM?
Anche se non hai bisogno di scriverlo nel tuo codice, è molto utile poterlo usare quando hai accesso al terminale a un server di database.
Inoltre, la maggior parte di ciò che rende la programmazione una sfida sta lavorando all'interno delle restrizioni che la vita ci impone: spesso lavoriamo con codice vecchio o vecchie versioni di database e non abbiamo l'opportunità di installa l'ultima libreria ORM per qualsiasi lingua con cui stiamo lavorando. In questa situazione avrai bisogno di qualsiasi strumento a tua disposizione.
Per il resto del tempo potresti non aver bisogno di SQL per i tuoi contenuti CRUD, ma c'è molto di più per SQL rispetto alle semplici query SELECT, INSERT, UPDATE e di base JOIN. Puoi fare cose molto intelligenti con esso e anche se non puoi usarli spesso, è utile sapere quali sono.
Sempre più spesso, penso che ci troveremo in un mondo post-SQL, tuttavia, la maggior parte dei servizi cloud utilizzano storage di tabella non SQL e, per il semplice tipo CRUD, non è necessario il pieno potere di SQL. Ma ciò non significa che non ci sarà alcun valore nel comprenderlo.
Inoltre, qualcuno deve sapere abbastanza per scrivere un sistema ORM migliore se quelli attuali non sono di molto. Li aiuterebbe se conoscessero SQL ...
Costruire applicazioni web su larga scala è completamente inutile e può rendere le cose molto più stressanti e perdite di tempo di quelle che devono essere. La ragione di ciò è che qualsiasi app su larga scala dovrebbe utilizzare un livello di persistenza della memoria (nella RAM) che dovrebbe essere la cache di memoria delle parti del DB che vengono usate frequentemente.
Se devi fare cose con dispositivi mobili, ecc. che non hanno molta memoria su cui lavorare, dove l'applicazione che si sta programmando è in esecuzione come "client" o app standalone su un dispositivo mobile, tablet , ecc., rispetto a cose come l'uso di SQL sono ancora comuni e sono importanti perché la memoria del dispositivo è così piccola che non è possibile memorizzare nella cache un sacco di cose in memoria.
La complessità e la quantità di SQL I non sono sufficienti per rendere ragionevole l'hooking di un framework ORM.
(Scrivo SQL forse una volta al mese, se)
Mi sono imbattuto in molti grandi corps con gli amministratori di database che temono attivamente gli sviluppatori che utilizzano gli strumenti ORM.
Sono gli amministratori di database coinvolti nell'ottimizzazione e nelle prestazioni.
E sì, gli strumenti ORM possono essere gestiti per fare cose del genere, ma ho visto posti in cui accettano solo una stored procedure (Sql Server) e ti interrogheranno su cosa stai facendo in esso.
Inoltre, gli strumenti ORM possono essere malamente abusati e produrre proprio come Sql scadente come scrivere lo Sql da solo.
One biggie - DDL & migrazioni di database. A volte devi ricamare quel materiale per aggiornare le cose senza rompere i dati esistenti.