Ogni istruzione SQL deve essere rivista da un DBA - comune?

Intendo tutto, non solo i cambiamenti di schema. Anche un semplice SELECT su una chiave primaria non può entrare in produzione, anche se è stato rivisto dal codice da altri sviluppatori (nel contesto), senza una revisione DBA di ogni istruzione, estratto dal codice e inviato con output EXPLAIN, dettagli di quanto spesso verrà chiamato, ecc., ecc.

Se sei stato in un ambiente simile, hai trovato un guadagno netto o un freno allo sviluppo? Come qualcuno che ha lavorato con i database relazionali per anni, trovo ingiustificato l'atteggiamento "gli sviluppatori non possono fidarsi di usare i database" e sono curioso di sapere quanto sia comune questa situazione. Per quello che vale, questo è solo per lo sviluppo web, non qualcosa di critico.

In uno dei miei precedenti lavori io (insieme ad altri tre programmatori) ero responsabile della revisione di ogni procedura memorizzata creata o aggiornata prima che entrasse in produzione per circa 40+ programmatori. Come revisore è stato un vero ostacolo per il mio tempo, ma nel complesso era ancora necessario perché con ciò molti sviluppatori commettono un errore di tanto in tanto. È nato perché avevamo programmatori offshore che scrivevano istruzioni SQL davvero pessime (saggiamente efficiente) e si erano rifiutati di imparare (quel team alla fine è stato chiuso).

Nel complesso abbiamo cercato:

• Utilizzo dell'indice: la query stava eseguendo una scansione completa della tabella?
• Manutenibilità: la query avrebbe dovuto essere cambiata in un paio di settimane perché c'era qualcosa che era stato codificato? E la query è leggibile?
• Efficienza complessiva: un raccordo interno potrebbe essere sostituito con un esistente? L'aggiunta di un aiuto con blocco aiuta?
• Problemi di blocco: la query bloccherebbe il database e impedirebbe gli aggiornamenti? Questo è successo più di quanto mi importi.

Molto spesso la maggior parte delle query non ha avuto problemi e abbiamo continuato. Ma ogni revisione ha richiesto tra 10 minuti e due ore a seconda della query. A una parte di me piaceva l'idea di fare recensioni perché impediva la temuta telefonata alle 2 del mattino perché alcuni rapporti stavano causando un problema con un'altra applicazione. Ma allo stesso tempo ho pensato che fosse un po 'eccessivo perché siamo tutti adulti e la persona che scrive la query dovrebbe fare tutto da solo.

Penso che le query complesse dovrebbero far parte della revisione del codice standard, ma non devono passare attraverso un DBA. Non è nemmeno necessario rivedere le istruzioni di inserimento / aggiornamento / eliminazione semplici. Inoltre, come autore di una query dovresti sapere quando è diventata troppo complessa e sapere quando chiedere una recensione da un DBA.

Aggiornamento Nel mio primo lavoro tutte le domande sono state scritte dai DBA e questo è stato un grande killer in termini di sviluppo. Ho dovuto inviare tutte le colonne che volevo, le tabelle in cui si trovavano le colonne e infine i miei criteri di ricerca. Anche le istruzioni di inserimento / aggiornamento / eliminazione di base sono necessarie per passare attraverso un DBA. Alla fine sono arrivato al punto in cui avrei potuto scrivere l'SQL che volevo, fargli dare un'occhiata e apportare le modifiche necessarie, quindi avvolgere una procedura memorizzata attorno ad esso, ma sono rimasti solo un paio d'anni. Quella particolare compagnia ha assunto molti neolaureati e questo è stato il modo in cui hanno assicurato che i nuovi ragazzi non scrivessero domande che uccidessero lo spettacolo.

Dipende totalmente dall'ambiente, dall'industria e dall'azienda.

Qualche esempio:

• Alla NASA, più livelli di controllo e revisione sono lo standard. Il più noto "avrebbe dovuto raddoppiare il controllo" fu quando una sonda fu inviata su Marte e gli Stati Uniti fecero calcoli in piedi, ma gli europei in metri. La sonda è andata persa.

• Ad una startup senza DBA (comune in questi giorni) non ci sarà alcuna revisione DBA e forse nemmeno una revisione programmatore (ad esempio, se non ci sono altri programmatori in azienda).

• In un'azienda il cui prodotto è un data warehouse di centinaia di milioni di righe, accertarsi che le query siano efficienti e corrette possono essere problemi chiave alla base del business che dovrebbero essere controllati.

Una società il cui prodotto principale è un sito Web prevalentemente statico con un numero limitato di interazioni con il database, può considerare il database e la sua efficienza meno rilevanti. È possibile che la società scelga di spendere il proprio "budget" di revisione nelle pagine statiche considerate più critiche.

Non ho mai lavorato in un ambiente del genere, sono sicuro che lo odierei. Mi viene in mente un pensiero per iniziare a tenere traccia di alcune metriche intorno a questo ...

• Quanto tempo impiega uno sviluppatore a estrarre sql dal codice e a prepararlo per l'invio a un DBA
• Quanto tempo impiega il DBA per rivedere sql?
• Con quale frequenza vengono richieste le modifiche dal DBA? Suddiviso per
  tipo di query ?

Tenere traccia di questo per un po 'di tempo probabilmente mostrerebbe quanto è trascinante rispetto a quanto sia efficace.

La maggior parte degli sviluppatori è assolutamente ignorante quando si tratta di database. Non sono nemmeno consapevoli della loro ignoranza. Anch'io ero uno sviluppatore ignorante.

Gli sviluppatori vivono in un mondo di ottimizzazione è malvagio. Quella mentalità non funziona quando si eseguono operazioni su un disco. Quella mentalità non funziona quando si sceglie un tipo di dati 8 volte più grande di quello che deve essere che fa sì che l'indice sia 8 volte più grande di quello che deve essere in modo che non possa più adattarsi alla memoria. Quella mentalità non funziona quando si programma contro un'API generica che aggiorna in modo ridondante tutte le colonne di una tabella (no grazie a bean Java).

Non sanno cos'è una scansione completa della tabella. Non sanno come elaborare i dati in una singola operazione insieme invece di aprire un cursore. Peggio di un cursore, interrogheranno i dati, quindi, riga per riga, li elaboreranno avanti e indietro nel database quando basterebbe un singolo aggiornamento semplice. Con conseguente prestazione ORRIBILE.

Non conoscono i gravi impatti della segnalazione rispetto a tabelle di grandi dimensioni. Forse la necessità di report richiederà la creazione di uno schema a stella e un feed di dati al suo interno. Il tuo sviluppatore medio interrogherà solo le tabelle esistenti e si chiederà perché ci vogliono 3 ore per l'esecuzione della query (questa è una cifra reale).

Le conoscenze del tuo sviluppatore medio saranno sufficienti per le app CRUD "medie" in cui un utente modifica semplicemente un record. Non sarà sufficiente una volta usciti dalla bolla di Ruby-on-Crack e nel mondo reale.

Dipende da quanto è grande il database e se è condiviso tra più applicazioni. Spesso al team DBA piace sapere quali query verranno eseguite in modo che possano assicurarsi che siano presenti gli indici corretti o che sappiano a chi comunicare se devono suddividere una tabella. E tendono ad essere un po 'meglio dello sviluppatore medio nel leggere i piani di esecuzione delle query e individuare i luoghi in cui è possibile specificare suggerimenti per migliorare le prestazioni. È anche un'opportunità per loro di ottenere un avviso che alcune query di grande impatto scenderanno nella prossima versione, in modo che possano raccogliere statistiche diverse per l'ottimizzatore.

Non ho lavorato in un ambiente simile, e nemmeno io.

C'è una differenza tra lavoro di squadra e burocrazia ostile. Come sviluppatore, mi piacerebbe avere input DBA su query difficili. Ma so quando chiedere aiuto.

Se non sono abbastanza competente per SELECTdomande semplici , dovrei essere licenziato.

L'ho visto fatto in un paio di posti diversi. È fantastico in teoria, ma raramente ho visto che è efficace. Ecco perché. In primo luogo, se hai un team di amministratori di database (o altre persone), in genere ho scoperto che la persona meno competente o meno apprezzata del gruppo ottiene il peso maggiore del lavoro di revisione. Perché tu dici? È perché, nessun altro vuole farlo, e tutti gli altri sono impegnati a fare altre cose che sono probabilmente più urgenti. Mai visto un DBA sedersi in giro e dire: "Amico, tutto funziona alla perfezione; posso semplicemente sedermi e navigare in rete. Vorrei avere qualcosa da fare." Neanche a me, almeno non quelli buoni. Sono occupati o più occupati di tutti gli altri. Ciò significa che la persona che è meno in grado è molto probabilmente sta facendo la revisione, e questa è esattamente la persona che non vuoi farlo. Il codice che vuoi rivedere è il codice davvero difficile che la gente guarda e lo trasmette come una sorta di magia nera. I DBA junior o semplicemente quelli cattivi, non saranno mai in grado di cogliere le sottigliezze di come funziona una query davvero difficile. Raramente, come mai, qualcuno dice mai: "Amico, non ho pensato di selezionare una singola riga da un tavolo usando la chiave primaria! Grazie DBA, sei un vero toccasana". Quindi, in questo scenario, in realtà tutto ciò che stai facendo è creare molto lavoro per poco valore. t pensa di selezionare una singola riga da una tabella usando la chiave primaria! Grazie DBA, sei un vero toccasana. "Quindi, in questo scenario, tutto ciò che stai facendo è creare molto lavoro per poco valore. t pensa di selezionare una singola riga da una tabella usando la chiave primaria! Grazie DBA, sei un vero toccasana. "Quindi, in questo scenario, tutto ciò che stai facendo è creare molto lavoro per poco valore.

In secondo luogo, è semplicemente più lavoro per il gruppo DB. Quello che probabilmente succederà anche se guardano altre cose è che lo daranno una rapida occhiata e qualcosa ci mancherà. Sono persone impegnate e la revisione del codice richiede molto tempo. In verità non è giusto che vengano incaricati di questo, perché è una scusa per tutti gli altri che sono pigri e li usano come uscita, che alla fine è ciò che accade. Qualcosa si interrompe nella produzione e lo sviluppatore sottolinea rapidamente "Bene, il DBA lo ha esaminato". Ora è vero per tutto il tempo, no, ma è vero per parte del tempo e spesso da parte di persone che hanno bisogno di rivedere il proprio codice. Quindi hai seppellito il DBA con un lavoro extra e hai costretto quella persona a essere responsabile degli errori di qualcun altro, quando quella persona probabilmente non lo fa

L'unico modo per risolvere veramente il problema è far scrivere a persone che sanno scrivere codice SQL. Di tanto in tanto dovrebbero ricevere input dai DBA? Certo che dovrebbero, ma ho sempre trovato, se non hai tempo di farlo bene la prima volta, quando troverai il tempo per sistemarlo.

Ho lavorato in quel tipo di ambiente. Tutte le modifiche al sistema sono state sottoposte a revisione paritaria da parte di colleghi appropriati. Per me significava solo che dovevo pianificare in anticipo e presentare le mie modifiche con qualche giorno di anticipo. SQL è andato ai DBA che alla fine avrebbero rilasciato l'SQL in produzione.

Il mio SQL di solito va bene, hanno riscontrato un paio di sciocchi errori. All'inizio mi sembra troppo burocratico, ma io lavoro in finanza. Hai visto cosa succede (se sei nel Regno Unito) qualche mese fa quando una grande banca qui ha incasinato un aggiornamento di routine e ha incasinato tutte le transazioni che hanno portato a milioni (almeno centinaia di migliaia) di persone incapaci di ottenere ai loro soldi.

Vorrei anche andare oltre. Verificherei il codice circostante e vedrei come vengono passate le variabili alla query. Spesso si vede come gli sviluppatori espongono la propria applicazione agli attacchi di iniezione sql a causa della mancanza di conoscenze di base (ipotesi false "questo non può essere hackerato").

Anche gli sviluppatori inesperti possono trascinare il database in ginocchio con un uso improprio di ORM o una query tutt'altro che ottimale.

Nel progetto più recente in cui lavoro, nessuno sviluppatore front-end è autorizzato ad accedere direttamente al database. Aumentano la richiesta di una funzione che restituisce un determinato set di dati e gli sviluppatori back-end lo preparano per loro. Funziona abbastanza bene, gli sviluppatori front-end scrivono l'interfaccia utente e elaborano i dati forniti dalle funzioni scritte dagli sviluppatori back-end.

Nel nostro team di sviluppo c'è un sotto-team di 4 sviluppatori di database esperti nella piattaforma DBMS che utilizziamo. Scrivono tutti gli SQL o almeno le revisioni e apportano modifiche per soddisfare i loro standard di codifica qualsiasi SQL scritto dagli sviluppatori .Net. Fanno parte del team di progetto. I DBA di produzione appartengono a un reparto completamente diverso e il loro lavoro è operativo. Non riesaminano il nostro codice o schema SQL e anche la distribuzione è gestita da script, tutto ciò che fanno è eseguire lo script. Il massimo che aiutano è nel tuning delle prestazioni.