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

In uno dei miei precedenti lavori, I (insieme ad altri tre programmatori) era responsabile della revisione di ogni stored procedure creata o aggiornata prima di essere messa in produzione per circa 40+ programmatori. Come recensore è stata una vera svolta per il mio tempo, ma nel complesso era ancora necessario perché con questo molti sviluppatori commettevano un errore una volta ogni tanto. È avvenuto perché avevamo programmatori off-shore che hanno scritto dichiarazioni SQL davvero pessime (efficiente) e hanno rifiutato di imparare (il team è stato chiuso).

Nel complesso abbiamo cercato:

• Utilizzo dell'indice: la query eseguiva una scansione completa della tabella?
• Manutenibilità - la query avrebbe dovuto essere modificata in un paio di settimane perché qualcosa era codificato in esso? E la query è leggibile?
• Efficienza globale - potrebbe essere sostituito un join interno con un esistente? Vuoi aggiungere un aiuto con blocco?
• Problemi di blocco: la query blocca il database e impedisce che si verifichino gli aggiornamenti? Questo è successo più di quanto mi interessi a pensare.

Il più delle volte la maggior parte delle query non ha avuto problemi e l'abbiamo spinta avanti. Ma ogni revisione richiedeva tra 10 minuti e due ore a seconda della query. Una parte di me è piaciuta all'idea di fare recensioni perché ha impedito la temuta telefonata 2 AM 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 sola.

Penso che le query complesse debbano essere parte della revisione standard del codice, ma non è necessario passare attraverso un DBA. Né è necessario rivedere semplici istruzioni di inserimento / aggiornamento / cancellazione. Inoltre, come scrittore di una query devi sapere quando è diventato troppo complesso e sapere quando chiedere una revisione da un DBA.

Aggiorna Nel mio primissimo lavoro tutte le domande sono state scritte dagli amministratori di database e questo è stato un grande killer per lo 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 / cancellazione di base 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 stored procedure attorno ad esso, ma ci sono voluti solo un paio d'anni. Quella compagnia in particolare ha assunto un sacco di neolaureati e questo è stato il modo in cui hanno assicurato che i nuovi ragazzi non scrivessero domande che hanno ucciso la performance.

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

Alcuni esempi:

• Alla NASA, i livelli multipli di controllo e revisione sono lo standard. Il più noto "dovrebbe avere il doppio controllo" era quando una sonda è stata inviata su Marte e gli Stati Uniti hanno eseguito calcoli in piedi, ma gli europei in metri. La sonda è stata persa.

• In una fase di avvio senza DBA (comune in questi giorni) non ci sarà alcuna revisione DBA ed eventualmente nessuna revisione del 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, assicurandoti che le query siano efficienti e corrette potrebbero essere problemi chiave al centro dell'azienda da verificare.

Una società il cui prodotto principale è un sito web prevalentemente statico con un numero limitato di interazioni tra database, può considerare il database e la sua efficienza meno pertinenti. Può essere che l'azienda scelga di spendere il suo "budget" di revisione sulle pagine statiche considerate più critiche.

Non ho mai lavorato in un ambiente del genere, sono sicuro che lo odierò. Un pensiero mi viene in mente per iniziare a tenere traccia di alcuni parametri intorno a questo ...

• Quanto tempo impiega uno sviluppatore a estrarre SQL dal codice e prepararsi deve essere presentato ad un DBA
• Quanto tempo impiega il DBA per rivedere lo sql?
• Quanto spesso sono richieste le modifiche da parte del DBA? Suddiviso dalla query
  digitare?

Tenere traccia di ciò per un po 'probabilmente mostrerebbe quanto di una resistenza sia contro quanto sia efficace.

La maggior parte degli sviluppatori è completamente 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-is-evil. Quella mentalità non funziona quando si eseguono operazioni su un disco. Quella serie mentale non funziona quando scegli un tipo di dati che è 8 volte più grande di quello che deve essere, il che fa sì che l'indice sia 8 volte più grande di quello che deve essere, quindi non può più adattarsi alla memoria. Questa mentalità non funziona quando si programma contro un'API generica che aggiorna in modo ridondante tutte le colonne in una tabella (non grazie ai bean Java).

Non sanno cosa sia una scansione di una tabella completa. Non sanno come elaborare i dati in un'unica operazione invece di aprire un cursore. Peggio di un cursore interrogheranno i dati, quindi il processo riga per fila andrà avanti e indietro nel database quando sarebbe sufficiente un solo semplice aggiornamento di plain-jane. Risultato in prestazioni ORRIBILI.

Non conoscono gli impatti gravi delle segnalazioni contro tabelle di grandi dimensioni. Forse la necessità di report richiederà la creazione di uno schema a stella e un feed di dati in esso. Il tuo sviluppatore medio si limiterà a interrogare le tabelle esistenti e si chiederà perché ci vogliono 3 ore per l'esecuzione della query (questa è una cifra reale).

La conoscenza del tuo sviluppatore medio è sufficiente per le app CRUD "medie" in cui un utente modifica semplicemente un record. Non sarà sufficiente quando usciranno dalla bolla Ruby-on-Crack e nel mondo reale.

Dipende da quanto è grande il database e se è condiviso tra più applicazioni. Spesso al team di DBA piace sapere quali query verranno eseguite in modo che possano assicurarsi che gli indici corretti siano a posto, o in modo che sappiano chi notificare se devono partizionare una tabella. Inoltre, tendono a essere leggermente migliori rispetto allo sviluppatore medio alla lettura dei piani di esecuzione delle query e dei punti di individuazione dei punti in cui è possibile specificare suggerimenti per migliorare le prestazioni. È anche una possibilità per loro di farsi un'idea che alcune query di grande impatto verranno discusse nella prossima versione, in modo che possano raccogliere statistiche diverse per l'ottimizzatore.

Non ho lavorato in un ambiente del genere, né lo farei io.

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

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

Ho visto questo fatto in un paio di posti diversi. È fantastico in teoria, ma raramente l'ho visto efficace. Ecco perché. In primo luogo, se hai una squadra di amministratori di database (o altre persone), ho generalmente riscontrato che la persona meno competente o meno gradita del gruppo ottiene il peso 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. Hai mai visto un DBA sedersi e dire "l'uomo è tutto perfetto, posso semplicemente sedermi e navigare in rete. Vorrei avere qualcosa da fare". Nemmeno io, almeno non quelli buoni. Sono occupati o più occupati di tutti gli altri. Ciò significa che la persona che è meno capace è molto probabilmente facendo la revisione, e questa è esattamente la persona che non vuoi farlo. Il codice che vuoi rivedere è il codice veramente difficile che la gente guarda e lo trasmette come una sorta di magia nera. I DBA Junior o semplicemente cattivi, non saranno mai in grado di cogliere le sottigliezze di come funziona una query davvero difficile. Raramente, come mai, qualcuno ha mai detto "Uomo non ho pensato di selezionare una singola riga da un tavolo usando la chiave primaria! Grazie DBA sei un vero toccasana". In questo scenario, in realtà, tutto ciò che stai facendo è creare molto lavoro con scarso valore.

In secondo luogo, è semplicemente più lavoro per il gruppo DB. Ciò che probabilmente accadrà anche se guardano ad altre cose è che daranno una rapida occhiata a questo aspetto e qualcosa verrà perso. Sono persone impegnate e la revisione del codice richiede molto tempo. In realtà non è giusto che vengano incaricati di questo, perché è una scusa per tutti gli altri essere pigri e usarli come un fuori, che in definitiva è ciò che accade. Qualcosa si interrompe nella produzione e lo sviluppatore fa notare rapidamente "Beh, il DBA lo ha revisionato". Ora è vero tutto il tempo, no, ma è vero parte del tempo e spesso da persone che hanno bisogno di avere il loro codice veramente rivisto. Quindi hai sotterrato il DBA con un lavoro extra e hai costretto quella persona a essere responsabile degli errori di qualcun altro, quando quella persona probabilmente non ha abbastanza tempo per correggere tutti gli errori attualmente in produzione.

L'unico modo per risolvere veramente il problema è quello di far scrivere alle persone che sanno come scrivere codice SQL. Dovrebbero ricevere informazioni dai DBA di volta in volta? Certo che dovrebbero, ma ho sempre trovato, se non hai il tempo di farlo bene la prima volta, quando hai intenzione di trovare il tempo per sistemarlo.

Ho lavorato in quel tipo di ambiente. Tutte le modifiche al sistema sono state riviste da peer 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.

Di solito il mio SQL va bene, hanno preso un paio di errori stupidi. All'inizio sembra eccessivamente burocratico, ma io lavoro nella finanza. Hai visto cosa succede (Se sei nel Regno Unito) alcuni mesi fa, quando una grande banca qui ha incasinato un aggiornamento di routine e incasinato tutte le transazioni che portavano a milioni (almeno a centinaia di migliaia) di persone incapaci di ottenere con i loro soldi.

Andrei anche oltre. Vorrei controllare il codice circostante e vedere come sono passate le variabili alla query. Capita spesso di vedere come gli sviluppatori espongono la loro applicazione agli attacchi sql injection a causa della loro mancanza di conoscenza di base ("questo non può essere violato" false ipotesi).

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

Nel progetto più recente a cui lavoro, nessuno sviluppatore front-end può accedere direttamente al database. Esse sollevano una richiesta per una funzione che restituisce un dato insieme di dati e gli sviluppatori back-end lo preparano per loro. Funziona piuttosto bene, gli sviluppatori front-end scrivono l'interfaccia utente e elaborano i dati forniti da funzioni scritte da sviluppatori back-end.

Nel nostro team di sviluppo è presente un sottogruppo di 4 sviluppatori di database esperti nella piattaforma DBMS che utilizziamo. Scrivono tutte le 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 SQL o lo schema e anche la distribuzione è programmata, tutto ciò che fanno è eseguire lo script. Il massimo che aiutano è l'ottimizzazione delle prestazioni.