SQL è importante se conosco bene i framework ORM? [chiuso]

Non ho alcuna seria esperienza in SQL e odio persino scrivere SQL invece di LINQ. Sono abbastanza felice con gli ORM.

Dal punto di vista del datore di lavoro e del settore, è importante conoscere SQL? Devo dominarlo? Le aziende che preferiscono SQL puro rispetto ai framework ORM sono un "dinosauro" nel mondo della programmazione?

Questo è difficile da spiegare a molti programmatori, perché se conosci solo l' SQL di base , in realtà non ti dà molto vantaggio rispetto alla stampella di un ORM. I concetti SQL più avanzati, tuttavia, sono una parte cruciale della differenza tra applicazioni che funzionano e applicazioni di alta qualità (in particolare, veloci e affidabili).

Sto assumendo qualcun altro progetta i database per voi, perché fare che senza conoscere SQL è appena al di là del pallido. Ma anche se stai solo sviluppando contro di loro, ecco solo un elenco parziale di tutte le cose che gli ORM tendono ancora a fare male o per niente:

• Query ricorsive e / o gerarchiche
• Parametri opzionali (in particolare traducendoli in predicati di intervallo)
• Tipi di dati definiti dall'utente
• Tipi specifici della piattaforma (gerarchyid SQL e TVP, array Oracle e tabelle nidificate, ecc.)
• Inserimenti / aggiornamenti / aggiornamenti / eliminazioni batch
• Suggerimenti sull'indice
• Suggerimenti sui blocchi (in particolare blocchi di aggiornamento e letture sporche)
• Gestione degli errori
• Join esterni: i loro set di risultati si associano male al modello OOP, molti ORM hanno il loro linguaggio di query ma è simile a conoscere lo stesso SQL;
• Modularizzazione tramite stored procedure e UDF, in particolare UDF in linea e query CROSS APPLY
• Utilizzo di OUTPUT / RETURNING per la gestione temporanea dei dati in più tabelle
• Query di paging efficienti
• Query basate su funzioni di windowing (rownum, rango, partizioni)

L'elenco potrebbe continuare all'infinito: molte di queste sono cose che un DBA alle prime armi non ha mai dovuto fare e uno sviluppatore alle prime armi non ne ha mai sentito parlare, ma sono molto importanti nelle app su larga scala.

Gli ORM sono davvero fantastici nel velocizzare il codice SQL davvero noioso , cioè tutto il CRUD ripetitivo e la mappatura e altri codici idraulici, quindi non c'è assolutamente vergogna nell'usarli e non ascoltare nessuno che dice di essere cattivo. Ma sicuramente hai ancora bisogno di imparare e sì, persino di padroneggiare SQL, ed essere pronto a scendere in comandi / query DB non elaborati quando l'ORM non sta assumendo il suo peso.

Assolutamente! L'SQL è ancora la lingua franca dei database e sebbene si possa fare molto con gli ORM, è necessario comprendere l'SQL per comprendere le decisioni che gli ORM prendono e l'SQL che generano. Inoltre, ci sono ancora molte cose che devi fare con sql personalizzato e anche le stored procedure. Siamo spiacenti, niente pranzo libero.

Sì, devi ancora conoscere SQL. Gli ORM sono un'astrazione che perde molto e non forniscono accesso alla piena potenza di SQL. Per le applicazioni giocattolo potresti essere a posto con conoscenze SQL limitate. Per le applicazioni aziendali, dovrai comprendere il database per ottenere prestazioni decenti dall'ORM. Inoltre, ci sono molte attività che sono molto più facilmente realizzabili con SQL che con un linguaggio applicativo. Ho visto programmatori Java passare giorni a scrivere codice per fare qualcosa che avrebbe potuto essere codificato in SQL in un'ora. La conoscenza di SQL è molto preziosa per chiunque scriva applicazioni che utilizzano un database relazionale.

Oggi l'abilità SQL è un must nell'IT. LINQ è una tecnologia solo Microsoft. Gli usi SQL vanno oltre lo sviluppo di applicazioni Web e client / server. Non puoi modellare database e fare ETL se non sei bravo con SQL. Potrebbe non essere necessario padroneggiare i dialetti SQL utilizzati in ORACLE e SQL Server per i loro prodotti Data Warehous, ma è necessario conoscere SQL standard. Le basi di SQL sono semplici, ci sono tonnellate di materiale per iniziare.

Se si interagisce con un database SQL, è necessario comprendere il codice SQL generato dall'ORM. È necessario comprendere i concetti inerenti ai database SQL e comprendere cosa l'ORM non può fare per voi. Gli ORM semplificano la vita (e sì, penso che lavorare senza di te ti qualifichi come un dinosauro in molti casi), ma sono strumenti (per astrarre cose che conosci), non stampelle (per impedirti di imparare).

Se rifiuti di imparare l'SQL, allora non hai nessun tipo di attività che tocchi i database SQL, con o senza un ORM, e dovresti trovare un altro tipo di lavoro.

Devo ammettere che sono un fan sfegatato di ORM e ho predicato i benefici di ORM per anni e ho avuto molto da dire sul perché ORM vince su SQL.

MA...

Devo ammettere che SQL è totalmente e totalmente richiesto nel mondo reale e ogni sviluppatore dovrebbe avere una buona conoscenza di SQL.

I proc SQL sono più veloci dell'ORM in quasi tutti i casi. Anche se nella maggior parte dei casi è possibile ottimizzare l'output ORM, farlo arrivare in un secondo vicino a procs SQL.

A volte, è necessario un SQL pesante per ottenere il risultato richiesto e queste query mostruose sono più facili e veloci da creare nei proc SQL.

Solo i miei due bit.

Verrà il momento in cui dovrai ottimizzare qualcosa di complesso che l'ORM sta creando. A quel punto in genere hai una query estremamente complessa da abbattere. Se non hai mai appreso le nozioni di base, come puoi aspettarti di iniziare a imparare SQL con le cose avanzate? Non capirai abbastanza nemmeno per iniziare. ORM nelle mani di una persona che capisce SQL - un buon strumento. ORM nelle mani di qualcuno che non conosce affatto SQL - disastro in attesa di accadere.

Uno dei motivi per cui SQL è fondamentale per comprendere i database è che i programmatori di applicazioni non pensano naturalmente in termini di set di dati. Ma l'unico modo in cui i database funzionano in modo efficiente è tramite set. Devi imparare a pensare in set prima ancora di provare a usare un ORM.

Mi ritrovo a forzare manualmente le query nei framework ORM il più delle volte. E mentre la maggior parte ha il proprio linguaggio di query, tutti sono ispirati a sql, il codice viene trasformato in sql e devi capire cosa non va leggendo quel sql quando (non se, quando) le cose vanno male o funzionano male.
Quindi, anche se non stai scrivendo sql direttamente, capendolo oltre un livello base (anche se probabilmente non avrai bisogno di imparare cose sulla scrittura di stored procedure, trigger, ecc. Se tutto ciò che farai è accedere ai database) dovrebbe conoscere la lingua abbastanza per comprendere il codice generato e modificarlo secondo necessità.

Prima di parlare della domanda, prima una piccola introduzione; Adoro gli ORM. E odio SQL. Adoro gli ORM perché nascondono il disordine ostile che è SQL e forniscono un buon modo integrato nel linguaggio di gestire il database.

Tuttavia, devo ammettere che SQL ha molti vantaggi, di cui quello più grande è la precisione. Posso praticamente discutere della complessità di una query SQL, senza una conoscenza dettagliata dello schema del database sottostante, semplicemente esaminando la query. Pertanto, quando utilizzo SQL, sono sempre in allerta e ho sempre un'intuizione su dove sta andando la complessità di un componente.

D'altra parte, quando uso gli ORM, sono così sopraffatto dalla facilità di integrazione del database, che dimentico letteralmente che esiste persino un database. Questo mi ha fregato più volte. Molte volte in passato, ho chiamato metodi ORM dall'aspetto innocente, che dietro le quinte chiamano join di database enormi e spaventosi, che distruggono le prestazioni.

Ecco perché per me la verità è da qualche parte nel mezzo. Adoro usare gli ORM e continuerò a farlo, ma devo stare più attento e studiare sempre le implicazioni (a livello di SQL) di qualsiasi chiamata al metodo ORM. Conoscere le implicazioni di uno strato di astrazione è oro puro in questo settore e giustificare l'uso dell'astrazione. Nient'altro, è come spararsi sul piede.

Se tutto ciò che ti viene richiesto è interagire con il database solo tramite l'applicazione che stai creando, probabilmente non ti serve. In alcune piccole aziende o team di sviluppatori, potrebbe essere necessario fornire supporto. È molto più facile connettersi al database di un client ed eseguire alcune istruzioni sql per vedere cosa sta succedendo con i loro dati.

Anche con un ORM buono e maturo inevitabilmente ti imbatterai in situazioni in cui emette un SQL inefficiente e renderà la tua vita molto più semplice se riesci a capire cosa succede nell'SQL generato. Detto questo, se sei molto competente con l'ORM e sai come utilizzare un profiler per il tuo DB preferito, potresti facilmente "fingere finché non lo fai".

La risposta a tutti questi tipi di domande ("devo sapere X?") È "imparala la prima volta che ne hai bisogno, se mai ne avrai bisogno".

È importante però non cadere nella trappola di fare le cose in modo meno efficiente perché non si è consapevoli o non si è disposti a imparare il modo efficace per farle.

In questo caso particolare, ad esempio, cosa fai se ti rendi conto che c'era un bug nel tuo programma che PostCounta volte rendeva il campo della tua tabella utente inaccurato.

Correggi il bug e ora devi aggiornare PostCount per tutti gli utenti. Come si fa?

Se scrivi un piccolo script usando ORM per farlo, allora sei molto inefficiente; farà una query SQL molto semplice.

Dato che queste situazioni sono abbastanza comuni, temo che tu sia caduto nella trappola sopra descritta!

Sì, hai ancora bisogno di SQL.

Non dare per scontato che qualcosa di "vecchio" sia in qualche modo indegno di considerazione. Le cosiddette tecnologie "legacy" sono quelle che esistono ancora dopo aver superato la prova del tempo. Non chiamiamo i computer Wang "eredità", hanno fallito e se ne sono andati.

Se mi chiedi, mi dà fastidio che la mia banca stia probabilmente usando COBOL su un mainframe o IBM i? Assolutamente no. Queste sono tecnologie solide, collaudate e vere. Indovina un po ', usano principalmente DB2 SQL. Sono molto più felice di fidarmi dei miei soldi lì, rispetto ai software sviluppati in un linguaggio alla moda del mese.

I dinosauri sono durati su questa terra molto più a lungo di quanto noi umani siamo stati in giro. E se leggi Jurasic Park (sì, i libri sono meglio dei film) allora te lo chiedo, vuoi davvero affrontare un branco di velociraptor iper-intelligenti o un T-Rex ostinato che non si arrende mai? Non essere morso sottovalutando i "dinosauri". ;-)

A parte i giochi e la ricerca (principalmente statistica), di cui non ho esperienza, sembra che l'accesso al database e le operazioni siano una delle poche aree in cui decisioni sbagliate portano a un notevole calo delle prestazioni. Sono un convinto sostenitore delle più potenti astrazioni di database nel codice e credo che linq, che lega le operazioni del database al linguaggio di programmazione, offre tutti gli strumenti del linguaggio (controllo del tipo, controllo della sintassi, tutte le cose che ti piacciono il tuo linguaggio di programmazione) pur continuando a darti molta potenza per fare ciò che vuoi è assolutamente fantastico. Sfortunatamente, non sempre funziona. Ciò significa che se il livello di astrazione sbaglia le sue ottimizzazioni e potresti aspettare secondi invece di microsecondi o minuti anziché secondi per il tuo risultato. Dal momento che questi sono tempi molto evidenti, devi ottimizzarli o la tua applicazione non "funziona": le prestazioni diventano il problema più grande della tua applicazione. Ciò significa che devi avvicinarti al metallo e ottimizzare a mano.

Quando arriviamo al punto che la manipolazione di set di dati di grandi dimensioni richiede, ad esempio, 3 ms quando lo si fa a mano e 100 ms quando si lascia che il livello di astrazione lo faccia per te, lascia che il livello di astrazione lo gestisca per te, perché potresti essere 30 volte più lento, ma sei ancora (probabilmente, per la maggior parte delle applicazioni) abbastanza veloce. La realtà della situazione è tuttavia che quando cerchi soluzioni ottimizzate a portata di mano in cui hai un tempo di risposta di 200 ms e quando lo strato di astrazione lo gestisce per te, l'algoritmo prende "solo" un colpo di prestazione 10 volte, hai un 2 secondi di ritardo, e poi ti preoccupi molto, poiché va da non così in fretta, a dolorosamente lento. Vedendo che le soluzioni di database relazionali non si adattano bene, Non credo che questo sarà risolto tra due o tre anni. Ciò significa che dovrai ancora passare al bare metal per un po 'di tempo quando si tratta di database più grandi, o la tua applicazione sarà così lenta da non poter resistere ai concorrenti.