C'è ancora bisogno di scrivere SQL?

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 supporti? Se sì, perché?

Per chiarezza: non sto chiedendo se i programmatori debbano conoscere SQL o se dovrei avere uno strumento SQL sul mio desktop. Sto chiedendo in particolare perché potrei averlo in codice (o config, o qualsiasi altra cosa) al contrario di un ORM.

• Scrivere SQL per eseguire query sui dati è più comodo rispetto a scrivere codice procedurale.
• Il tuo ORM, sebbene bello da vedere, genera un SQL orribilmente lento in alcune aree critiche.
• È necessario sfruttare le funzionalità esposte dal proprio RDBMS che non sono / non possono essere rese disponibili tramite il proprio ORM.
• Ogni volta che scrivi SELECT * FROM..., Dio uccide un gattino. E tu odi i gattini.
• Non stai utilizzando un ORM, OOP o un linguaggio moderno.

Scrittura di SQL complessi

Gli ORM sono ottimi per le cose di base. Tuttavia, per situazioni complesse dovrai scrivere SQL.

Quindi in breve, c'è sicuramente bisogno di SQL e rimarrà sempre tale.

• Visualizzazioni
• trigger
• vincoli
• Pacchetti (SSIS, DTS, ecc.)
• Ogni volta che è necessario controllare con precisione il flusso di esecuzione

ORM non ti aiuta a costruire, ottimizzare o automatizzare il database. Ti dà solo un modo alternativo per interagire con il database una volta che hai fatto tutte quelle cose.

Sicuro:

• Generalmente ORM incapsula molto, ma alla fine dovresti sapere cosa succede dietro le quinte. Questo è fondamentale per prestazioni e scalabilità. Sebbene all'interno dell'applicazione non scrivo molto SQL, ma so più o meno come sono SQL o DDL.
• Direct SQL è spesso utile per scrivere query di sola lettura. Molto più semplice da formulare nel linguaggio di query ORM e puoi anche limitare il set di risultati (ad es. 'Seleziona ID da .....').
• ORM non dovrebbe assolutamente tenerti lontano da SQL. Uso molto SQL per le query ad hoc direttamente sul client DB (come mysql-client). Ti dà un'interfaccia uniforme molto bella e funzionalità di raggruppamento.

Gli ORM esistono a causa della mancata corrispondenza dell'impedenza tra le nostre implementazioni di DB relazionali comuni e le nostre funzionalità del linguaggio OO. Sono solo un ponte, ma la maggior parte della gente tratta SQL come il formaggio Limburger nel frigorifero.

Se puoi legittimamente affermare che utilizzerai sempre il tuo ORM o altri livelli di accesso ai dati astratti invece di trattare SQL / stored procedure / viste come interfacce di prima classe, probabilmente starai 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 validazione finale.

Gli ORM sono uno strumento nella casella degli strumenti dei programmatori. Hanno i loro problemi. Alcuni esempi sono:

• Impossibile controllare sql
• Soffre di n + 1 problema

Se sai cosa stai facendo, puoi effettivamente utilizzare un ORM per sostituire gran parte del tuo codice CRUD. Non sono altrettanto efficaci per cose complesse, sono difficili da ottimizzare (si sa che le prestazioni sono una delle parti critiche della progettazione del database, non emulare oggetti) e sono decisamente orribili e pericolose nelle mani di qualcuno che non lo fa capire o scrivere SQL da soli.

Voglio anche sottolineare che non è facile eseguire in modo efficace rapporti complessi con un ORM. Inoltre, se non impari l'SQL semplice nella roba semplice, come raggiungerai il punto in cui puoi scrivere SQL complessi per i rapporti? Non ho mai lavorato in un'applicazione che non avesse esigenze di segnalazione e spesso piuttosto complicate.

Né gli ORM sono utili per la maggior parte dei processi BI o ETL. Né sono utili per le query di amministrazione del database o per trovare informazioni nelle tabelle di controllo e annullare una particolare serie di modifiche al database. Ci sono molte cose che sono ancora fatte in modo più efficace 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 tempo e sforzi extra senza un reale guadagno rispetto al metodo originale (e spesso una vera perdita di prestazioni), perché le stai usando diverse da quelle che sono "alla moda" in questo momento.

A volte un client desidera solo una query semplice e veloce per restituire dati per un report, esportazione, datadump, ecc. E desidera attendere che venga sviluppato un intero programma.

Inoltre, un buon programmatore SQL può sempre scrivere SQL più veloce ed efficace di qualsiasi altro ORM che abbia mai usato. Inoltre, ho scoperto che molte persone hanno semplicemente il punto ORM sulle procedure memorizzate - ignorando davvero i benefici dell'ORM perché gli ORM non sono grandi per i processi complessi.

Inoltre, quando si utilizza un database come Oracle con un linguaggio di procedura molto ricco e potente, è possibile fare molto senza mai aver bisogno di un "programma". PL / SQL su Oracle nelle mani giuste è molto veloce ed efficace.

Se si desidera utilizzare un database da soli, sì. La maggior parte degli ORM che ho provato a utilizzare non erano sufficienti o non coprivano il mio database. Inoltre, come hai intenzione di risolvere i problemi o scrivere query personalizzate che non sono coperte?

È ancora necessario per la scrittura di trigger e stored procedure. Le procedure memorizzate potrebbero non essere più utili, ma in alcune situazioni sono comunque molto utili. SQL può essere richiesto anche per alcuni join multi-tabella particolarmente pelosi.

Sì, puoi evitare di scrivere SQL. Ma finirai per scrivere HQL invece (o Linq, o DQL ...)!

Seriamente, sono un grande fan degli ORM e penso che si possa evitare di usare SQL puro per la maggior parte del tempo. Ma dobbiamo ricordare che un ORM è solo una grande astrazione, e tutte le grandi astrazioni perdono ...

(Ma per quanto riguarda il problema N + 1: questo è legato al caricamento lento, e la maggior parte degli strumenti ORM ha un modo di richiedere il caricamento desideroso, 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. È allora che 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, è abbastanza utile poterlo utilizzare quando si ha accesso terminale a un server di database.

Inoltre, la maggior parte di ciò che rende la programmazione di una sfida sta lavorando all'interno delle restrizioni che gli insiemi di vita noi- spesso ci stiamo lavorando con il vecchio codice, o vecchie versioni di basi di dati e non hanno la possibilità di installare l'ultima libreria ORM per qualsiasi lingua siamo lavorando con. In quella situazione avrai bisogno di qualsiasi strumento a tua disposizione.

Il resto del tempo potresti non aver bisogno di SQL per le tue cose CRUD, ma in SQL c'è molto di più delle semplici query SELECT, INSERT, UPDATE e JOIN di base. Puoi fare cose molto intelligenti con esso e anche se potresti non usarle spesso, è utile sapere quali sono.

Sempre più, penso che ci troveremo in un mondo post SQL, tuttavia, la maggior parte dei servizi cloud utilizza l'archiviazione di tabelle non sql e per un semplice lavoro di tipo CRUD non è necessaria la piena potenza di SQL. Ma ciò non significa che non ci sarà alcun valore nel comprenderlo.

Inoltre, ovviamente, qualcuno deve sapere abbastanza per scrivere un sistema ORM migliore se quelli attuali non sono all'altezza. Li aiuterebbe se conoscessero SQL ...

Per la creazione di applicazioni Web su larga scala è del tutto superfluo e può rendere le cose molto più stressanti e perdere tempo di quanto devono essere. La ragione di ciò è che qualsiasi app su larga scala dovrebbe fare uso di un livello di persistenza della memoria (nella RAM) che dovrebbe essere parti della memoria cache del DB utilizzate di frequente.

Se devi fare cose con dispositivi mobili, ecc. Che non hanno molta memoria con cui lavorare, in cui l'applicazione da programmare è in esecuzione come "client" o app autonoma su un dispositivo mobile, tablet, ecc. cose come usare SQL sono ancora comuni e sono importanti perché la memoria sul dispositivo è così piccola che non è possibile memorizzare nella cache molte cose in memoria.

La complessità e la quantità di SQL che scrivo non sono sufficienti per rendere ragionevole l'aggancio di un framework ORM.

(Scrivo SQL forse una volta al mese, se)

Mi sono imbattuto in molti grandi corpi con DBA che temono attivamente gli sviluppatori che usano gli strumenti ORM.

Sono i DBA che sono coinvolti nell'accordatura e nelle prestazioni.

E sì, gli strumenti ORM possono essere gestiti per fare cose del genere, ma ho visto posti in cui accetteranno solo una procedura memorizzata (Sql Server) e ti faranno domande su cosa ci stai facendo.

Inoltre, gli strumenti ORM possono essere gravemente maltrattati e produrre altrettanto povero SQL come scrivere da soli.

Un grosso problema: migrazioni DDL e database. A volte è necessario ricamare a mano quella roba per aggiornare le cose senza rompere i dati esistenti.