Alcuni anni fa ho lavorato a un'applicazione scritta da qualcuno che non aveva mai chiaramente imparato come funzionano i database SQL. Mi è stato fornito un rapporto sui problemi da correggere: la pagina di riepilogo dello stato principale, che era sempre stata lenta, ora aveva iniziato a essere così lenta che stava subendo il timeout di esecuzione dello script del server (di 3 minuti) durante il rendering. Sembrava che il numero di client nel sistema aumentasse, il tempo per il rendering della pagina di stato stava aumentando quadraticamente .

Non mi ci è voluto molto per notare il problema, ovvero che la pagina utilizzava una query che amalgama dati da due diversi tavoli, nessuno dei quali aveva indici . Poiché ogni tabella aveva dimensioni che crescevano in O (n) con il numero di client, la query richiedeva O (n ^ 2) tempo per l'esecuzione perché stava recuperando ogni riga della prima tabella e per ognuna di quelle righe stava recuperando ogni riga della seconda tabella per confrontarli.

La soluzione del problema richiedeva pochi minuti e chiunque capisse come funzionano i database SQL sarebbe stato in grado di farlo altrettanto rapidamente . L'autore originale no, quindi ha lasciato una soluzione totalmente inadeguata.

Devi capire come (almeno in termini generali) funziona una tecnologia per evitare di commettere errori orrendi come questo.

Non sottovalutare la possibilità che tu debba effettivamente entrare nel database e interrogarlo direttamente come parte di un processo di debug. Se tu mai finisci per farlo, vorrai sicuramente sapere tutto sulla tecnologia del database e su come è strutturato il tuo particolare database. Forse non succederà. Ma se lo fa (e nella mia esperienza lo fa sempre ad un certo punto) avrai bisogno di quella conoscenza.

Ma supponiamo che non avrai mai bisogno di cercare direttamente nel database per nessuna ragione. Diciamo che stai usando l'ORM in modo coerente con tutte le migliori pratiche stabilite dalla comunità. È potrebbe creare un'app performante senza gravi errori / colli di bottiglia / inefficienze nei dati. Ma se non capisci davvero il database sottostante, non capiresti davvero perché stai facendo le cose come sei. Peggio ancora, non veramente capire come le migliori pratiche si applicano al tuo caso d'uso specifico. Questi fatti dovrebbero seminare dubbi sul fatto che stai creando la soluzione ottimale. La tua soluzione potrebbe funzionare, ma non sarai in grado di dire "questa è la soluzione migliore" con una reale sicurezza. Se non puoi dire questo, non sei un grande vantaggio agli occhi della tua azienda e se lo dici e ti sbagli, ti sembrerà terribile.

Al di là delle difficoltà filosofiche che ho sul non imparare i fondamenti del tuo stack tecnologico, mi occupo di motivi concreti per conoscere il tuo stack da cima a fondo su base giornaliera. Nella mia azienda abbiamo un enorme monolite che gestisce enormi quantità di dati. Le cose sono ben modellate, ma nell'applicazione ci sono dozzine di dozzine di tipi di oggetti e le relazioni tra loro sono un'incredibile rete di chiavi esterne e tabelle di associazione. Sinceramente, se non si guarda nell'SQL e ci si immerge nell'app (anche se tutto è modellato correttamente nell'app e utilizza l'ORM e le best practice stabilite per quell'ORM), capire come ottenere questo bit di informazione dato questo altro bit qui può essere un compito quasi impossibile. Ma se puoi immergerti nel DB, puoi vedere tutti i campi in ogni modello, seguire le connessioni tra le tabelle, capire un percorso da un pezzo all'altro, testarlo con una query, quindi cercare i modelli appropriati da fare attraverso l'ORM in modo rapido ed efficiente. Non sarei la metà della risorsa per la mia azienda che io sono se non avessi un alto livello di comfort con l'hardware bare metal.

Solo fino a un punto

Come sviluppatore di software, probabilmente dovrai interrogare e aggiornare il database e sapere come funziona il DB è fondamentale per evitare query non valide, join inefficienti e così via. potresti avere un DBA dedicato che può decidere dove aggiungere gli indici per partizionare il database, ma non puoi contare su di esso, non nelle piccole aziende e non sempre in quelle grandi.

Tuttavia

Mentre dovresti sapere quali sono gli indici e come dovrebbero essere usati, non è necessario sapere come lavorano internamente. I dettagli di implementazione interna sono proprio questo: dettagli di implementazione.

Sapere come controllare un piano di query SQL e creare il codice di conseguenza in parte parte dell'API che il DB espone. Conoscendo gli algoritmi interni e le strutture dati che utilizza per raggiungerlo? Non. Così tanto. Per analogia, dovrei sapere le implicazioni sul rendimento del salvataggio di file su disco. Non ho bisogno di preoccuparmi di come viene implementato il mio filesystem.

Tuttavia a

Se, come mostrano i commenti chiarificatori, la domanda riguarda la comprensione dell'accesso ai DB e il fatto di fare affidamento esclusivamente sugli ORM e altre astrazioni di codice, la risposta è in modo schiacciante "sì, dovresti conoscere l'accesso al DB". Non tutti i progetti utilizzano o possono utilizzare un ORM e gli ORM non sono ideali per determinate attività (rapporti, inserimenti collettivi e altro).

Vale assolutamente la pena! Essere uno sviluppatore full stack consente di produrre in modo efficiente soluzioni a valore aggiunto. Ho visto troppo spesso interruzioni della comunicazione e sviluppo silo ... triplo il tempo di sviluppo e metà della qualità.

Alla fine della giornata, più abilità hai, più preziosa sarai.

Se ti ostini a non sapere nulla di auto , sarei felice se tu eseguissi il servizio dei freni sul mio? Penso di no.

I database sono notevolmente diversi dalle strutture dati con le quali sei abituato a lavorare in programmazione. Hanno le loro stranezze e idiosincrasie e altre cose che ti morderanno nel Performance dell'Applicazione se non ne hai la conoscenza.

Ho incontrato persone con questa mentalità "Non ho bisogno di sapere i database"; la maggior parte di loro considera i database come nient'altro che fogli di calcolo e produce applicazioni che hanno prestazioni terribilmente negative.

Detto questo, non devi sapere in che modo i database funzionano internamente .

Fai conoscere le cose logiche; Tabelle, indici, viste e simili.

Non resta intrappolato nei dettagli dell'implementazione di come un particolare DBMS gestisce queste cose; tutti lo fanno in modo diverso l'uno dall'altro (e talvolta tra le versioni di se stessi !), quindi una "panoramica" generale ti servirà al meglio.

Devi assolutamente sapere. Ad esempio, se il tuo database sta memorizzando le date, devi sapere che tipo di precisione puoi aspettarti. Se stai memorizzando un timestamp in un campo DATE , dovresti sapere se il database sta per troncare il tuo valore al secondo più prossimo (o peggio al giorno più vicino). Dovresti anche sapere che i valori provenienti da una colonna NUMBER(9,2) devono essere memorizzati in una variabile a virgola mobile, mentre quelli in una NUMBER(15,0) possono essere memorizzati come numeri interi. Potresti anche trovare utile sapere piccole strane come le colonne CHAR di Oracle riempite in bianco alla lunghezza specificata, mentre le colonne VARCHAR2 non lo sono. E il loro tipo di dati LONG memorizza effettivamente stringhe di lunghezza variabile, non numeri.

Ogni database ha i suoi capricci e devi sapere cosa sono (o almeno cosa cercare).

Capire come funzionano le cose sotto il cofano ti aiuterà a eseguire il debug delle query per le prestazioni e l'amp; considerazioni sull'archiviazione.

Ad esempio, una query di intervallo funzionerà meglio con un tipo di indice B-tree. E quando si effettuano i join, è possibile aggiungere suggerimenti al motore di query sull'utilizzo dei join HASH o MERGE. E sul lato fisico, è possibile distribuire tabelle in un database su diverse partizioni del disco fisico per ridurre al minimo la contesa della testa (probabilmente ancora adatto anche con gli SSD).

Per prima cosa è necessario essere chiari su ciò che SQL è e non è. SQL è un linguaggio di query e un linguaggio di manipolazione dei dati utilizzato per accedere e manipolare i dati in un database relazionale. Ma lo schema e gli oggetti dati (tabelle, colonne, indici, vincoli) nel database non sono "in SQL", SQL è solo una lingua possibile per interrogare e manipolare i dati.

Per poter lavorare efficacemente con un database relazionale, è necessario comprendere tabelle, colonne, tipi di dati, chiavi primarie, chiavi esterne e indici. È inoltre necessario comprendere le basi della query: proiezione, filtri, join. Devi capire le basi della normalizzazione.

Ma nessuna di queste cose in linea di principio richiede di toccare SQL. Potresti essere in grado di progettare lo schema del database in una finestra di progettazione della GUI e potresti essere in grado di scrivere query e aggiornamenti in un altro linguaggio come SqlAlchemy per Python o Linq per .net. Alcuni sostengono addirittura che questi linguaggi siano una rappresentazione più pura del modello relazionale rispetto a SQL.

Quindi in teoria il tuo amico ha ragione - non hai bisogno di imparare l'SQL. Ma hai ancora bisogno di sapere come funzionano i database relazionali, e quando lo sai, SQL è piuttosto facile da imparare, dato che si tratta solo di una sintassi.

Sebbene non sia necessario, è abbastanza comodo conoscere SQL, poiché è possibile interrogare qualsiasi database direttamente in SQL senza la necessità di un livello di traduzione separato. E dal momento che tutte le esercitazioni, i libri e gli esempi utilizzano SQL, sarà difficile evitare di impararlo.

Mi sono imbattuto in un problema in cui i numeri seriali venivano memorizzati come numeri decimali a 10 cifre in un database e letti in numeri interi a 32 bit in Java. Questo andava bene fino a quando non abbiamo raggiunto il nostro primo numero seriale che era maggiore di 2G, quindi non poteva essere rappresentato nel numero intero con segno a 32 bit di Java. Comprendere i tipi di dati DB potrebbe aver impedito questo problema.