Non ho alcuna esperienza seria in SQL e odio anche scrivere SQL invece di LINQ. Sono abbastanza felice con gli ORM.
Dal punto di vista dei datori di lavoro e del settore, è importante conoscere SQL? Devo padroneggiare su di esso? Le aziende che preferiscono i framework SQL puri su ORM sono un "dinosauro" nel mondo della programmazione?
Questo è difficile da spiegare a molti programmatori, perché se conosci solo SQL di base , in realtà non ti dà molto di un vantaggio rispetto alla stampella di un ORM. I concetti SQL più avanzati, tuttavia, sono una parte cruciale della differenza tra le applicazioni che funzionano rispetto alle applicazioni di alta qualità (in particolare, veloci e affidabili).
Suppongo che qualcun altro progetta i database per te, perché fare che senza conoscere SQL è appena oltre il limite. Ma anche se ti stai sviluppando solo contro di loro, ecco solo una lista parziale di tutte le cose che gli ORM tendono ancora a fare male o per niente:
L'elenco potrebbe continuare - molte di queste sono cose che un DBA inesperto non ha mai dovuto fare, e uno sviluppatore alle prime armi non ha mai nemmeno sentito parlare - ma sono molto importanti nelle app su larga scala.
Gli ORM sono davvero ottimi per accelerare il codice SQL noioso - cioè tutto il CRUD ripetitivo e la mappatura e altri codici idraulici, quindi non c'è assolutamente vergogna nell'usarli e non ascolta qualcuno che dice di essere cattivo. Ma sicuramente hai ancora bisogno di imparare e sì, anche di master SQL, ed essere pronto a scendere in comandi / query RA non elaborati quando l'ORM non sta tirando il suo peso.
Assolutamente! SQL è ancora la lingua franca dei database e, sebbene si possa fare molto con gli ORM, è necessario comprendere SQL per comprendere le decisioni che gli ORM fanno e l'SQL che generano. Inoltre, ci sono ancora molte cose che devi fare con SQL personalizzato e stored procedure pure. Spiacente, nessun pranzo gratis.
Sì, è ancora necessario conoscere SQL. Gli ORM sono una astrazione molto permeabile e non forniscono accesso a tutta la potenza di SQL. Per le applicazioni giocattolo potresti essere a posto con una conoscenza SQL limitata. Per le applicazioni aziendali, dovrai comprendere il database per ottenere prestazioni decenti dall'ORM. Inoltre ci sono molte attività che sono molto più facili da fare con SQL che con un linguaggio applicativo. Ho visto i programmatori Java passare giorni a scrivere codice per fare qualcosa che potrebbe essere stato codificato in SQL in un'ora. La conoscenza di SQL è molto utile per chiunque stia scrivendo applicazioni che utilizzano un database relazionale.
L'abilità SQL è un'abilità oggi indispensabile nell'IT. LINQ è una tecnologia Microsoft Only. Gli usi SQL vanno oltre lo sviluppo di applicazioni Web e client / server. Non puoi modellare i database e fare ETL se non stai bene 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 SQL sono semplici, ci sono tonnellate di materiale per iniziare.
Se si interagisce con un database SQL, è necessario comprendere l'SQL generato dall'ORM. Devi comprendere i concetti inerenti ai database SQL e devi capire cosa il tuo ORM non può fare per te. Gli ORM semplificano la vita (e sì, penso che lavorare senza uno ti qualifichi come un dinosauro in molti casi), ma sono strumenti (per astrarre cose che conosci), non stampelle (per impedirti di imparare).
Se ti rifiuti di imparare SQL, non hai alcun 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 appassionato fan degli ORM e ho predicato i vantaggi di ORM per anni e ho avuto molto da dire sul motivo per cui ORM supera SQL.
MA ...
Devo ammettere che SQL è totalmente e assolutamente necessario nel mondo reale e che ogni sviluppatore dovrebbe avere una buona conoscenza di SQL.
I proc SQL sono più veloci dell'ORM in quasi tutti i casi. Anche se puoi ottimista l'output ORM nella maggior parte dei casi, fallo arrivare in secondo piano rispetto ai proc SQL.
A volte, hai bisogno di un SQL pesante per ottenere il risultato che ti serve, e queste query monster sono più facili e veloci da creare nei proc SQL.
Solo i miei due bit.
Arriverà un momento in cui devi 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 imparato le basi, come puoi aspettarti di iniziare ad imparare SQL con le cose avanzate? Non capirai abbastanza da iniziare. Gli ORM nelle mani di una persona che comprende SQL - un buon strumento. Gli ORM sono nelle mani di qualcuno che non conosce affatto l'SQL - un disastro che aspetta 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 è da set. Devi imparare come pensare nei set prima ancora di tentare di usare un ORM.
Mi trovo a forzare manualmente le query nei framework ORM il più delle volte. E mentre la maggior parte ha il proprio linguaggio di interrogazione, quelli sono tutti ispirati da 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 si comportano male. < br> Quindi, anche se non stai scrivendo direttamente sql, comprenderlo oltre un livello base (anche se probabilmente non avrai bisogno di imparare cose su come scrivere stored procedure, trigger, ecc. Se tutto quello che devi fare è accedere ai database) dovrebbe conoscere abbastanza la lingua per capire il codice generato e modificarlo se necessario.
Prima di parlare della domanda, prima una piccola introduzione; Amo gli ORM. E odio SQL. Adoro gli ORM perché nascondono il disordine ostile dell'utente che è SQL e forniscono un bel modo integrato di gestire il database con il linguaggio.
Tuttavia devo ammettere che SQL ha molti vantaggi, e quello più grande è la precisione. Posso discutere sulla complessità di una query SQL, senza una conoscenza dettagliata dello schema del database sottostante, semplicemente passando attraverso la query. Pertanto, quando uso SQL, sono sempre attento e ho sempre intuito su dove si stia dirigendo la complessità di un componente.
D'altro canto, quando si usano 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 i metodi ORM dall'aspetto innocente, che dietro le quinte chiamano enormi e spaventosi join di database, che distruggono le prestazioni.
Ecco perché per me la verità è una via di mezzo. Mi piace usare gli ORM e continuerò a farlo, ma devo essere più attento e studiare sempre le implicazioni (a livello SQL) di qualsiasi chiamata al metodo ORM. Conoscere le implicazioni di uno strato di astrazione è oro puro in questo business e giustificare l'uso dell'astrazione. Qualcos'altro, è come spararsi sul piede.
Se tutto ciò che devi fare è interagire con il database solo se l'applicazione che stai creando, probabilmente non ne hai bisogno. In alcune aziende più piccole o in team di sviluppatori, potrebbe essere necessario fornire supporto. È molto più facile connettersi al database di un cliente ed eseguire alcune istruzioni SQL per vedere cosa sta succedendo con i propri dati.
Anche con un ORM buono e maturo, inevitabilmente ti imbatterai in situazioni in cui emetterebbe un SQL inefficiente e renderà la tua vita molto più semplice se riuscirai a ingannare ciò che succede nell'SQL generato. Detto questo, se sei molto competente con l'ORM e sai come usare un profiler per il tuo DB di scelta, potresti facilmente "fingere finché non lo fai".
La risposta a tutti questi tipi di domande ("devo conoscere X?") è "impara la prima volta che ne hai bisogno, se ne avrai mai bisogno".
È importante non cadere nella trappola di fare le cose in modo meno efficiente perché non sei consapevole o non sei disposto a imparare il modo efficace per farlo.
In questo caso particolare, ad esempio, che cosa fai se ti accorgi che c'è stato un bug nel tuo programma che ha causato il campo PostCount della tua tabella utente a volte inaccurato.
Risolvi il bug e ora devi aggiornare PostCount per tutti gli utenti. Come lo fai?
Se scrivi un piccolo script usando ORM per fare ciò, sei molto inefficiente; farà una query SQL molto semplice.
Dato che queste situazioni sono abbastanza comuni temo di cadere nella trappola sopra descritta!
Sì, hai ancora bisogno di SQL.
Non saltare sul presupposto che qualcosa di "vecchio" sia in qualche modo indegno di considerazione. Le cosiddette tecnologie "legacy" sono quelle che sono ancora in circolazione dopo aver superato la prova del tempo. Noi non chiamiamo i computer di Wang "legacy", hanno fallito e sono spariti.
Se me lo chiedi, mi dà fastidio che la mia banca stia probabilmente usando COBOL su un mainframe o IBM i? Assolutamente no. Sono tecnologie solide, provate e vere. Indovina cosa, usano principalmente DB2 SQL. Sono molto più felice di aver fiducia nei miei soldi lì, che nel software sviluppato in una lingua alla moda del mese.
I dinosauri sono durati su questa terra molto più a lungo di noi umani. E se leggi Jurasic Park (sì, i libri sono meglio dei film) allora ti chiedo, vuoi davvero affrontare un pacco 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 le decisioni sbagliate portano a un impatto molto ampio sulle 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, fornisca 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 un sacco di energia per fare ciò che desideri è assolutamente fantastico. Sfortunatamente, non sempre funziona. Ciò significa che se il livello di astrazione ottiene le sue ottimizzazioni errate e potresti aspettare secondi invece di microsecondi o minuti anziché secondi per il risultato. Poiché si tratta di tempi molto evidenti, è necessario 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 la mano.
Quando arriviamo al punto in cui la manipolazione di set di dati di grandi dimensioni richiede ad esempio 3 ms quando si fa a mano e 100 ms quando si lascia che il livello di astrazione lo faccia per te, lascia che sia il livello di astrazione a gestirlo per te, perché potresti essere 30 volte più lento, ma sei ancora (probabilmente, per la maggior parte delle applicazioni) abbastanza veloce. Tuttavia, la realtà della situazione è che quando si guardano soluzioni ottimizzate a mano in cui si ha un tempo di risposta di 200 ms e quando il livello di astrazione lo gestisce per te, l'algoritmo prende "solo" un hit di 10 volte, hai un 2 secondi di ritardo, e poi ti preoccupi molto, dal momento che non è così veloce, per rallentare dolorosamente. Vedendo che le soluzioni di database relazionali non si adattano bene , I non pensare che questo sarà risolto in due o tre anni. Ciò vuol dire che per un po 'di tempo devi ancora scendere sul bare metal quando si tratta di database più grandi, o la tua applicazione sarà così lenta, non può reggere il confronto con i concorrenti.
Leggi altre domande sui tag sql entity-framework orm