In che modo gli amministratori di database potrebbero essere più "programmatori"?

Le risposte e i commenti sulla versione dba.se e sulla versione programmers.se della domanda "Quali sono gli argomenti a favore o per mettere la logica dell'applicazione nel livello del database?" stanno rivelando molto bene la divisione tra DBA e programmatori in alcuni luoghi di lavoro.

Cosa potrebbero fare diversamente i DBA per lavorare meglio con i programmatori su problemi come questo?

Dovremmo:

• Studiare gli strumenti e le lingue che i nostri programmatori stanno usando per capire le difficoltà che affrontano, in particolare quando lavorano con database ben progettati?
• Incoraggiare i programmatori a essere meglio istruiti sui database e sui vantaggi di avere una logica aziendale a livello di database?
• Cambiare il modo in cui definiamo le interfacce per i nostri dati, ad esempio utilizzando API transazionali più intuitive per i programmatori (ad esempio per problemi come la compatibilità con le versioni precedenti)?

Dal punto di vista del programmatore, direi che ciò che desideriamo di più è standard coerenti, ben definiti e implementati per il modo in cui il livello di dati verrà progettato e costruito. Sono disposto a giocare come vuoi nella tua sandbox, devi solo dirmi cosa vuoi e non cambiare le regole in ogni momento. Dovrebbe essere implementato lo stesso per tutti, anche per i superprogrammergod. Se fai delle eccezioni per lui, allora vuoi che io lo sostenga e lo cambi, ma lo implementi nel modo giusto che non funziona per me.

E per favore non dirmi di non farlo in quel modo e di andartene. Lavora con me per mostrarmi cosa vuoi e perché la tua strada è migliore. Se capisco lo farò sempre. Quando non capisco, è più difficile rispettarlo. Non voglio essere un DBA. Adoro programmare, non voglio il tuo lavoro e se sei un buon DBA, sarò il tuo più grande fan.

Sono stato un DBA MySQL negli ultimi 6,5 anni. Ho anche trascorso circa 16 anni come sviluppatore e ho interagito con molti DBA. Molti pragmatici. Alcuni sono odiosi. Alcuni non hanno idea di cosa significhi essere un DBA.

Sono giunto a questa conclusione:

Tecnicamente parlando, i DBA che hanno una o più delle seguenti qualità sono le migliori con cui lavorare:

1. Ho trascorso anni come sviluppatori stessi
2. Conoscere la teoria dei database
3. Comprendere bene come l'RDBMS funziona internamente
4. Avere una conoscenza superiore del sistema operativo

DBA molto disciplinati e competenti hanno molto da condividere e offrire. Potrebbero vedere le prestazioni del database da una prospettiva non considerata dagli sviluppatori. Gli sviluppatori sanno cosa vogliono dal database. I DBA sanno come essere "educati" nel database.

Per quanto riguarda le personalità, ci saranno sempre conflitti, meschinità e forse persino invidia. Una cosa è certa: in nessun ordine particolare, i DBA e gli sviluppatori sono come mariti e mogli (sono felicemente sposato da 16 anni con progetti in corso [4 figli]).

Indipendentemente da chi è visto come il marito e chi è visto come la moglie, si applicano questi principi:

1. uno deve consultare l'altro
2. uno deve valutare la prospettiva dell'altro
3. bisogna prendere decisioni per il bene di entrambe le parti
4. bisogna sostenere, e non sabato, la decisione presa
5. uno non deve denigrare l'altro se le decisioni portano a conseguenze negative
6. bisogna rallegrarsi del contributo di entrambe le parti al successo delle decisioni
7. si deve consultare un'autorità superiore (HA) se una decisione non può essere concordata reciprocamente

Questi sette (7) principi si applicano tanto sul posto di lavoro, specialmente nel regno IT.

Comunicando ogni passaggio, tutti dovrebbero:

1. impaginare le loro aspettative
2. generare rispetto per la capacità dell'altra parte di fare la propria parte sulla base delle prestazioni passate
3. avere fiducia e fiducia nel fatto che l'altra parte possa completare il proprio incarico
4. all'altezza delle nostre aspettative
5. acquiese sotto la guida dell'HA (vedi principio 7)

Non c'è spazio per la microgestione in questo. DBA NON DOVREBBE DARE agli sviluppatori come pensare come DBA. Gli sviluppatori NON DOVREBBERO DARE ai DBA come essere sviluppatori. Le decisioni finali sulle prestazioni e l'utilizzo del database devono spettare ai DBA . Le decisioni finali sulle esigenze dell'applicazione devono spettare agli sviluppatori . Questa simbiosi deve essere mantenuta sempre.

PENSIERI FINALI

Il Principio n. 7 richiede la partecipazione attiva e la supervisione da parte della HIGHER AUTHORITY (HA), ovvero project manager, team leader, lead developer. Il tuo HA sa meglio come entrambe le parti lavorano individualmente e come entrambe le parti dovrebbero lavorare insieme. Se l'HA non stabilisce regole di base per entrambe le parti o se l'HA non riesce a guidare le parti individualmente e insieme, i progetti si fermeranno sempre ad un certo punto e metteranno in pericolo l'esistenza stessa (impiego) dello Sviluppatore, il DBA, o persino l'HA.

Avere squadre sedute in diverse sezioni / piani sembra in qualche modo incoraggiare la mentalità "noi contro loro".

Sedere un DBA nel bel mezzo del team di sviluppo è un ottimo modo per abbattere il muro del programmatore / DBA. Sia il DBA che i programmatori ne trarranno beneficio, se rimangono di mentalità aperta e mettono da parte i loro ego.

La comunicazione faccia a faccia, specialmente quando si condividono idee, è molto più efficace della posta elettronica e ha meno possibilità di provocare sensazioni forti a causa di incomprensioni.

Questo genere di cose varia enormemente da un luogo all'altro. Nel mio sito attuale, la linea tra sviluppatori e DBA è davvero molto sfumata: anche noi (DBA) scriviamo PL / SQL e loro (sviluppatori) analizzano i piani di query. Ci consideriamo tutti pari, semplicemente con competenze e responsabilità diverse. Questo è molto divertente: recentemente la compagnia ha saltato a bordo del carro DevOps . La comunità del database non lo capisce affatto; abbiamo sempre lavorato così. Inutile dire che stiamo lavorando enormemente in questo modo: il livello del database è di gran lungala parte più affidabile dello stack tecnologico dell'azienda, è facile da usare (dal momento che abbiamo le competenze nel team DBA per comprendere l'applicazione a un livello profondo, e gli sviluppatori hanno l'esposizione DBA per comprendere le operazioni 24/7/365 e come per strutturare le loro app per questo).

Ma so cosa intendi quando parli del tipo di sviluppatore "sbagliato". È autodidatta, che di per sé è una cosa nobile, ma lungo la strada ha raccolto una diffidenza verso qualsiasi tipo di istruzione formale. Lui non sa quello che non sa , e si risente chiunque tenti di illuminarlo, lo vede come un insulto alla sua abilità di auto-apprendimento. Ha imparato lo stile imperativo della programmazione, perché puoi impararlo senza nessuna di quelle cose teoriche di cui i tipi di CS parlano sempre (beh, male; tutti hanno bisogno di conoscere big-Oe simili pezzi di teoria). Ha imparato anche un po 'di OO, solo perché deve usare Java. Ma un buon professionista del database - sviluppatore o DBA - deve sentirsi a proprio agio a pensare in uno stile dichiarativo, a pensare alla teoria degli insiemi, alle forme normali, anche a comprendere l'algebra relazionale e il calcolo. È molto, molto difficile comunicare con queste persone, perché sono attivamente ostili a tutto ciò che potrebbe scacciarle dalla loro zona di comfort, che è in gran parte limitata a come formattare qualcosa su una pagina web. Se pensano ai database, pensano che una tabella sia come una classe e una riga sia come un oggetto. Questi ragazzi faranno letteralmente, SELECT * FROM TABLEfiltreranno e ordineranno i risultati nel loro codice. Davvero, davvero non capiscono perché un database sia migliore di un file flat (e non pensano così segretamente che chiunque usi un database relazionale sia un idiota).

Permettetemi di darvi un esempio reale: recentemente ho parlato con uno di questi tipi dei problemi legati al rollback di una versione del nostro software dopo che era entrato in produzione, se un problema fosse passato oltre il controllo qualità. Ho spiegato che mentre potremmo ripristinare la sua applicazione (uno dei tanti che accedono al database), dovrebbe essere in grado di funzionare con il database ancora distribuito. Mi ha chiesto perché, e ho detto, beh, in quelle nuove tabelle e colonne, ci saranno dati reali sui clienti. Ha poi detto, quindi basta copiarlo in una tabella temporanea, qual è il problema. Lo fissai incredulo: quando un cliente chiama e dice, i miei soldi sono scomparsi dal mio conto, cosa gli diciamo, va bene, è in un tavolo temporaneo? Semplicemente non l'ha capito quando hai a che fare con i soldi degli altri, devi comportarti come un adulto responsabile. Per quanto ne so, non lo fa ancora; non è più con noi.

Il campo MySQL è stato così per molto tempo; direbbero che non hai bisogno di transazioni, chiavi esterne, ecc., se pensavi di averlo fatto solo perché non avevi idea di cosa stavi facendo, ecc. ecc. (poi, quando sono cresciuti, li hanno aggiunti tranquillamente). Questi sono i tipi di persone per cui sono stati sviluppati ORM come ActiveRecord o Hibernate, in modo da poter scrivere applicazioni di database senza mai dover toccare SQL. L'uso di queste tecnologie che considero una bandiera rossa - questa non è una società che valorizza le competenze DBA. Quello che vogliono davvero è una babysitter ...

Come programmatore, comprendere meglio il database mi ha reso un programmatore migliore. Quando sono diventato amministratore del database questo è diventato ancora più importante, quindi credo che l'educazione sia la chiave.

I DBA dovrebbero guidare pazientemente gli sviluppatori trattandoli come professionisti competenti. Pochi programmatori, quando viene mostrata la differenza tra un'operazione impostata e un'operazione riga per riga sul lato client, si opporranno all'idea. Condividiamo alcuni degli stessi obiettivi: velocità dell'applicazione, sicurezza dei dati, manutenibilità, ecc. Ciò si applica non solo alla domanda di logica dell'applicazione, ma anche a tutti gli aspetti dell'interazione del database. I programmatori vogliono usare meglio i loro strumenti e più il DBA può mostrare loro come usare meglio lo strumento di database, più ne trarranno beneficio entrambi.

Indipendentemente dall'infrastruttura che supportiamo, dobbiamo supportarne gli utenti. Molti utenti sono sviluppatori, quindi supportiamo gli sviluppatori per consentire loro di sfruttare al meglio tale infrastruttura. Per poterlo fare, dobbiamo capirci a vicenda, tenendo conto delle diverse idee e punti di vista. Avere una visione delle opinioni di entrambe le parti aiuta a migliorare le cose per l'azienda e questo è il nostro obiettivo combinato. Rendi il supporto IT aziendale il più efficace possibile.

In molte organizzazioni vediamo alcuni tipi di dba in esecuzione in modalità god. Il più delle volte questi non sono quelli che ottengono un buon punteggio se si misura la competenza ..... Spesso nascondono la loro - mancanza di - conoscenza dietro un muro di parole.

Secondo me non ha nulla a che fare con l'essere "programmatore amichevole" più con l'essere professionale. Per un dba significa che dobbiamo essere in grado di spiegare perché facciamo le cose che facciamo ed essere pronti a riconsiderare la decisione di leasing se aiuta, senza perdere gli obiettivi normali come disponibilità, scalabilità, recuperabilità e prestazioni. Per il programmatore significa che deve comunicare con il dba, a volte per insegnare al dba, a volte per imparare dal dba. Il mio motto su questo è: lascia che il primo giorno in cui non impari nulla sia il giorno in cui la bara si chiude sopra la mia testa. La normale collaborazione, combinando team con sviluppatori e dba aiuta sicuramente a semplificare le cose.

Penso che parte del problema sia la prospettiva. Dbas e analisti di dati e sviluppatori di database devono gestire i dati nel tempo. Gli sviluppatori di applicazioni si preoccupano di come far funzionare le cose quando le inviano alla produzione. Non si preoccupano così tanto di come saranno i dati tra sei mesi, a condizione che non ci siano errori quando vengono distribuiti.

Ma i dati devono convivere con i risultati di decisioni miopi che causano la perdita di integrità dei dati o l'inserimento di record duplicati e quindi tentano di spiegare perché i dati non sono corretti. I DBA sono quelli che hanno a che fare con il problema delle prestazioni del processo che ha funzionato bene quando c'erano solo un migliaio di record, ma ora impiega ore con 100.000.000 di record.

I database sono più difficili da refactoring, quindi i DBA si preoccupano di farlo bene la prima volta. Gli sviluppatori non vedono alcun problema nel refactoring lungo la strada.

Gli sviluppatori non vedono alcun problema nel far funzionare il database come se fosse orientato agli oggetti, le persone del database sanno che non è il modo più efficace o efficiente per archiviare o ottenere i dati.

Gli sviluppatori di applicazioni spesso si occupano solo di un piccolo sottoinsieme di record ma non di grandi importazioni / esportazioni di dati o report. Le cose che funzionano bene per inserire un record, non funzionano quando si parla di importazione di un milione. La logica aziendale nell'applicazione (che spesso non è accessibile all'applicazione di reporting) non aiuta lo scrittore di report a ottenere gli stessi risultati per un milione di record di ciò che viene mostrato sullo schermo un record alla volta.

Un'altra parte del problema è la mancanza di rispetto da entrambe le parti. Ho incontrato più di alcuni sviluppatori di applicazioni che pensano che il lavoro sui dati non sia difficile o interessante e che credono che faresti questo lavoro solo se non riesci ad hackerarlo nel loro mondo. Le persone tendono a non reagire bene all'essere trattate come se fossero stupide e inutili. Alcuni DBA, d'altra parte, tendono a trattare anche gli sviluppatori di applicazioni con mancanza di rispetto e tendono a mettere le loro attività di revisione di ciò che gli sviluppatori stanno facendo nel database come una priorità bassa (che può avere quando sono presenti grandi database di produzione complessi). Possono rifiutare di ascoltare o rispondere. Chi vuole che il suo intero progetto venga sospeso fino a quando il DBA non lo esamina due settimane dopo? E poi ti dice che è inaccettabile e devi riscrivere il tutto?

Nel corso dei molti anni da quando ho iniziato con SQL Server (1998), molti sviluppatori mi hanno spiegato come svolgere il mio lavoro. È interessante che sappiano tutti più di me oltre a essere superbi sviluppatori .net. In realtà, sono anche architetti e dovrebbero fare cose più grandi del codice scimmia.

Forse questo è l'atteggiamento sbagliato da parte mia: ma è un atteggiamento sviluppatore abbastanza comune in molti negozi. Lo fanno anche l'un l'altro, ricorda: guarda i combattimenti iniziare quando suggerisci le revisioni tra pari.

Lascerò le correzioni ad altre risposte (finora sono d'accordo al 100% con le 2) ma aggiungo che la cultura di gestione e di negozio deve supportare e alimentare anche la collaborazione.

Come sviluppatore, tutto ciò di cui ho bisogno è sapere come vuoi che comunichi ciò di cui ho bisogno. Se sto chiedendo qualcosa di ridicolo, ho bisogno che tu me lo dica - e se me lo dici, ci crederò perché hai un track record per l'integrità. Se non capisci cosa sto chiedendo, prenditi il ​​tempo per spiegarmi cosa pensi che intendo e mi prenderò il tempo di ascoltare.

... Tema comune, giusto ... Comunicazione ... comunicazione ... comunicazione.

Non c'è davvero modo migliore per dirlo. Gli sviluppatori ricevono un segno di spunta perché "che DBA mi ha detto che non si poteva fare - sono sicuro che l'ultima volta gli è stato smentito". I DBA vengono spuntati perché "quello sviluppatore non capisce cosa devo fare ogni volta che cambia le sue specifiche".

Gli sviluppatori e i DBA, come affermato da @Rolando, devono capirsi. Quando tutto si riduce ad esso, entrambi parliamo di "Ones & Zeros" - penseresti che sarebbe una buona partita. Abbiamo 2 regni di responsabilità: i DBA hanno dati, gli sviluppatori ottengono il resto del computer. Ma senza dati, i programmatori non avrebbero davvero molto da fare.

Non abbiamo un DBA ed è doloroso a volte. Quel pezzo di me che voleva diventare un DBA un decennio fa si rabbrividirà quando vedrò alcune delle cose che facciamo. Se domani assumessimo un DBA, penso che bacerei il terreno su cui lui / lei ha camminato.

In alcune aziende, forse in molte, lo sviluppo del prodotto tende a ignorare chiunque non scriva in un linguaggio compilato. Vieni tempo di rilascio, c'è resistenza perché gli amministratori di rete, i DBA, gli amministratori di sistema, l'assistenza agli utenti, ecc. Hanno ciascuno la dovuta diligenza da completare. Spesso ci sono mal di testa perché non sono stati considerati gli aspetti chiave dell'ambiente. Ciò provoca naturalmente tensioni tra le squadre.

Di chi è la colpa qui? Sig.ra Communication.

Gli sviluppatori devono capire in che modo verrà implementato il codice ambientale. Le persone devono ricevere un equo avviso per adattarsi. Laddove l'ambiente non può adattarsi per qualsiasi motivo (sicurezza, attrezzatura, politica), il software deve adattarsi. Se ciò accade durante il processo di progettazione e implementazione, tutti sono felici. Se non inizia fino al momento del dispiegamento, è un mondo di dolore.

Sì, i team devono parlare (e ascoltare) l'un l'altro, ma il project manager / prodotto deve creare un ambiente in cui ciò può accadere.

Sono stato fortunato, in molti posti in cui ho lavorato, il rispetto reciproco e la comunicazione sono stati parte della cultura.

Una cosa che un buon DBA deve capire è la politica dei dati. Ho insegnato programmazione e progettazione di database a programmatori esperti e alcuni DBA redatti per alcuni anni. Una domanda che sarebbe venuta regolarmente era questa: come mai tutti i database nel mio negozio sono così politici?

Ecco la mia risposta standard: se il database è utile, allora stai condividendo i dati. Se condividi dati, condividi il potere. Quando il potere è condiviso, la politica accade.

Non importa se ami la politica o odi la politica. Se hai intenzione di fare un buon lavoro di database, abituati.

Per inciso, alcuni di voi hanno lavorato solo in un ambiente di sviluppo. Ci sono DBA che lavorano dal lato della produzione della recinzione e hanno poca interazione con gli sviluppatori. Potresti pensare che ci sia meno politica nella produzione. C'è più. I grandi database di produzione tendono ad essere a livello aziendale e mission-critical.

Un po 'di umiltà potrebbe aiutare per alcuni di voi. ;)

Ci sono ovviamente argomenti validi per entrambi gli approcci, ti suggerisco di iniziare riconoscendolo. Lo sviluppo del software consiste nel fare i giusti compromessi. Se è una strada a doppio senso, forse anche i DBA dovrebbero tenere una mente aperta.