Chi è responsabile della correzione delle revisioni del codice SQL non riuscite? [chiuso]

Questa recensione sta accadendo troppo tardi nel processo. Queste recensioni dovrebbero accadere mentre un dev termina un pezzo di lavoro, non prima del rilascio effettivo.

Ci deve essere un modello comune che stai vedendo ad esempio. indici errati, uso di cursori, ecc. Forse dovresti mettere insieme un foglio per presepe di ciò che rifiuterai e di cosa vorresti sostituire.

Per quel che vale, sembra che gli sviluppatori stiano mettendo troppa logica aziendale nel database.

C'è una costante confusione su questo ed è causato dal fatto che ci sono due diversi tipi di DBA: DataBase Architect e DataBase Administrator.

Molti sviluppatori lavorano con un architetto di database che progetterà le strutture del database e scriverà le stored procedure. Tuttavia, gli amministratori di database vivono spesso in team IT che eseguono backup, senza sapere nulla della codifica o delle pratiche di progettazione.

Sembra che i tuoi sviluppatori si aspettino che tu sia l'Architetto, dove sei un Amministratore. Penso che sia necessario correggere questa aspettativa con loro e quindi non avrai questi problemi. Inoltre, se sei solo un amministratore che non capisce il codice o l'ingegneria che è stata utilizzata per progettare le strutture e scrivere le stored procedure, è molto probabile che gli sviluppatori non prendano sul serio le tue critiche sul loro lavoro. Se hai suggerimenti o problemi con il lavoro di ingegneria, potrebbe essere meglio se puoi ottenere un database Architect con più know-how ingegneristico per sostenerne quelli per gli sviluppatori.

Inoltre, devo chiedermi perché stai esaminando l'SQL che gli sviluppatori scrivono se non sei un ingegnere esperto nella lettura di stored procedure complesse. Sembra che il management stia cercando di convincere il proprio dipartimento IT a fare ciò che fa il proprio dipartimento di ingegneria, senza capire che sono competenze completamente diverse. Potresti voler sollevarlo con la gestione.

DBA come architetto:

• Se il team DBA sta rifiutando il codice, allora sì, il team DBA dovrebbe fornire il motivo per cui sta rifiutando il codice.
• Se il team DBA rifiuta il codice perché è inefficiente, il team DBA dovrebbe probabilmente riscrivere il codice per renderlo efficiente e restituirlo agli sviluppatori. Gli sviluppatori devono convalidare che il codice che hai riscritto passa ancora i test.
• Se il team di DBA rifiuta il codice perché implementa in modo non corretto i requisiti, il team DBA dovrebbe effettivamente scrivere il codice da solo. Se conoscono i requisiti, ha molto più senso avere esperti SQL che scrivono codice SQL su alcune API concordate dal team DBA e dal team di sviluppo.

DBA come amministratore:

• Il team DBA non dovrebbe essere incaricato della revisione del codice. Un team di questo tipo probabilmente non avrebbe le competenze per rivedere il codice in modo efficace e sarebbe piuttosto solo un'approvazione "timbro di gomma" che si sente bene per il management, ma in realtà non migliora il processo.

Puoi solo apportare modifiche nel contesto di quali informazioni e competenze hai. Poiché non hai i requisiti, devi presupporre che i risultati del codice esistente siano corretti. Qualsiasi modifica apportata alle prestazioni non dovrebbe modificare i risultati. È facile da testare.

Potresti essere in grado di apportare modifiche per migliorare il codice senza modificare il codice stesso. Le query possono essere analizzate per vedere se un indice potrebbe migliorare le prestazioni. Altre impostazioni del database o modifiche hardware possono essere fatte anche.

In una certa misura, il tuo processo di revisione sta quasi chiedendo ai DBA un timbro di approvazione. Se vuoi fare di più, devi richiedere i requisiti, essere coinvolto nello sviluppo e richiedere la tua approvazione prima del processo di sviluppo.

Generalmente, quando un DBA ha un problema con una query è perché è lento . A tale riguardo, spetta al programmatore risolvere la query, perché in realtà sanno che cosa dovrebbe fare la query, fanno parte del normale flusso di lavoro di sviluppo delle applicazioni e saranno probabilmente responsabili delle modifiche in futuro; tuttavia, è molto probabile che il DBA dovrà assistere nel processo di ottimizzazione. Pochissimi programmatori che conosco possono guardare in modo affidabile una query e un piano di query e capire come rimuovere i colli di bottiglia.