In che misura un amministratore di database deve conoscere i linguaggi di programmazione a livello di sistema o di applicazione (ad esempio .NET o PHP) oltre a "solo SQL"?
Ai fini di questa domanda, per questa risposta non viene considerata alcuna versione specifica dello standard SQL (SQL ANSI 86, SQL ISO 87, SQL: 2008) poiché la domanda riguarda le lingue desktop o server al di fuori del regno di SQL.
Risposte:
Dipende.
In un grande negozio, forse non perché hai migliaia di server da gestire e i tuoi strumenti sono forniti. In un piccolo negozio, probabilmente avrai bisogno di maggiori conoscenze perché hai un mandato più ampio.
I linguaggi di scripting (ad esempio PowerShell, cmd.exe) sono sempre utili sebbene per il monitoraggio, la distribuzione ecc. Ho spesso avuto alcuni script Perl che dovevo mantenere (quasi). Poi ci sono i pacchetti ETL assortiti che dovresti conoscere.
Detto questo, la maggior parte dei DBA (che conosco) sarebbe in grado di scrivere roba CLR di base o conoscere bene PL / SQL. Per me, la linea di demarcazione sta conoscendo i modelli o l'architettura più ampi di .net o Java. Non ne ho bisogno come sviluppatore DB o DBA. Allo stesso modo in cui .net o PHP o Java Monkeys non capiscono la progettazione del database o l'architettura o il codice come me.
Personalmente, ho deciso di smettere di inseguire l'ultima o la migliore lingua client anni fa e concentrarmi sul lavoro con il database. Questo non mi rende un "non programmatore": se dovessi, avrei bisogno di impararlo di nuovo.
Ho conosciuto i DBA per cavarsela con poca o nessuna abilità di programmazione, ma ogni DBA che abbia mai considerato un bene aveva almeno ragionevoli capacità di programmazione. Uno o due che mi viene in mente avevano un background di sviluppo sostanziale ed erano abbastanza bravi sviluppatori a pieno titolo. C'è una giusta quantità di open-source utensili scritte da persone che lavorano come amministratori di database nel loro lavoro di giorno e IIRC il tizio che ha scritto ROSPO usato per lavorare come un DBA.
A seconda del ruolo che potresti trovare, scrivere o mettere a punto le query, scrivere script per automatizzare le attività o consultare la progettazione delle applicazioni. In alcuni casi potresti pensare a un sacco di server tramite OEM o altri strumenti di monitoraggio.
I moderni ambienti di sviluppo "enterprise" come .Net o Java sono abbastanza complessi che uno sviluppatore può intraprendere una carriera solo specializzandosi in essi. Come DBA, in particolare nello spazio di sviluppo, avere una conoscenza pratica di C # o Java potrebbe non danneggiare, ma probabilmente non passerai molto tempo a codificarli.
Probabilmente otterrai più chilometraggio da qualsiasi strumento di scripting utilizzato sulla tua piattaforma, anche se molti sistemi espongono API .Net, Java, COM o web service. Se devi codificare qualcosa con queste API, avrai bisogno almeno di una conoscenza pratica di base di qualcosa che può consumare quell'API. Tuttavia, per fare ciò non sono in genere necessarie competenze avanzate di architettura dell'applicazione.
Alcuni sviluppatori avranno forti capacità di database, ma la paura irrazionale dei database è abbastanza comune nei circoli di sviluppo. Molti sviluppatori inoltre non riescono mai ad aggirare il paradigma delle "operazioni operative" che sta alla base di SQL. Come Dev DBA puoi trovarti a gestire le conseguenze di ciò e forse devi intervenire nel codice di procedura memorizzata per risolvere i problemi di prestazioni.
Anche l'ETL e gli strumenti che circondano il database possono rientrare nel mandato del DBA. Ho visto un sacco di ruoli DBA pubblicizzati che sembravano implicare una notevole quantità di lavoro di sviluppo back-end. Questo sarà più comune nelle aziende più piccole. Un poster recente voleva integrare metriche personalizzate in Oracle Enterprise Manager, che ha un'API plugin per farlo. È abbastanza comune vedere requisiti come questo alzarsi, ed essenzialmente l'unico modo per farlo è scrivere un codice di colla.
Esistono molti "Strumenti di lavoro" che lavorano nell'IT e possono svolgere un lavoro utile nonostante il parocalismo. Tuttavia, quando gli strumenti si esauriscono, spesso l'unico modo per fare qualcosa è effettivamente scrivere un po 'di codice per farlo. Qui è dove le capacità di programmazione separano gli uomini dai ragazzi.
Direi non tipicamente, ma non fa mai male. SQL Server è abbastanza grande da non pensare che una persona possa padroneggiare l'intero prodotto. Sono un DBA da SQL Server 4.2 e mi considero un esperto in molte aree, ma ammetto che non sarei in grado di scrivere una query MDX senza Google a portata di mano in ogni fase del processo.
Quello che sto cercando di dire è che non puoi essere un esperto in tutto. Essere un ottimo DBA significa che dovresti essere bravo in T-SQL, ma probabilmente non sei molto bravo in .NET, o almeno non altrettanto efficace di altri che possono concentrare il loro tempo su .NET.
Powershell è buono a sapersi, così come i dettagli di SSIS. Oltre a ciò, lascia gli altri linguaggi di sviluppo agli sviluppatori.
È stata la mia esperienza che, sebbene la maggior parte dei DBA abbia una sorta di background di sviluppo, non sono affatto tenuti a scrivere codice. Gli ottimi DBA con cui ho lavorato hanno una vasta conoscenza di una varietà di argomenti tra cui script di shell, sistemi operativi e conoscenze specialistiche di applicazioni (ad esempio: PeopleSoft).
Avevo un istruttore di amministrazione del database alla scuola elementare che ci ha fornito un elenco di domande a cui qualsiasi buon DBA (Oracle) dovrebbe essere in grado di rispondere: (posterò solo alcuni dei punti salienti dall'elenco di circa 40)
(Oracle) I DBA devono conoscere queste cose per essere efficaci. La maggior parte degli sviluppatori che conosco (che codificano contro Oracle) sarebbero difficili da rispondere anche a uno o due di questi correttamente.
Se sei il DBA, probabilmente stai lavorando nel regno delle prestazioni e della sicurezza (tra gli altri). Ciò potrebbe comportare la profilazione e l'assistenza nell'ottimizzazione delle applicazioni client su cui stanno lavorando gli sviluppatori. Quindi non sarebbe certo male conoscere le basi delle lingue utilizzate dagli sviluppatori e come interfacciarsi con il server di database. Per SQL Server, questo è probabilmente .NET. Per MySQL, probabilmente una combinazione di php o java.
Ad esempio, se il server è sottoposto a pressioni per i thread client, aiuta a essere in grado di informare gli sviluppatori che dovrebbero utilizzare istanze singleton per le loro ObjectDataSource in modo che possano riutilizzare una singola connessione al database. Inoltre, assicurati di utilizzare correttamente le query con parametri per limitare l'iniezione SQL. Roba del genere.
Non farai alcuna programmazione nel senso di sviluppare applicazioni client se sei strettamente un DBA, ma dovresti sapere come funzionano (in generale).
Bene, vediamo, Oracle usa PL / SQL che è molto simile a Pascal (un linguaggio che era usato per produrre il codice dell'app desktop ma che è caduto negli ultimi anni, e gli sviluppatori sono passati a Delphi, che alcuni sono passati da lì a .NET) e Oracle ora supporta anche Java per alcune attività. Poiché un DBA Oracle deve conoscere tutti gli aspetti del sistema per essere apprezzato, direi che conoscere Pascal e Java sarebbe un requisito.
TSQL ha la capacità di scrivere codice gestito .NET (CLR) per alcune delle funzionalità di Sql Server e, quindi, un buon DBA dovrebbe probabilmente essere a conoscenza di questo (ma non sempre può essere utilizzato nelle versioni precedenti, quindi molto dei DBA tende a evitare questa caratteristica nella mia esperienza).
Quindi questi sono i due grandi, e quelli a cui la maggior parte delle persone si riferisce quando chiedono come stai chiedendo. Non conosco tutti gli altri motori per sapere cosa fanno e non supportano, ma so che molti altri hanno l'integrazione del linguaggio oltre a SQL.
Sono abbastanza convinto che solo i grandi negozi con grandi applicazioni hanno bisogno di un DBA non programmabile, poiché i piccoli negozi con database semplici possono cavarsela con lo sviluppatore / DBA tuttofare. Affinché un DBA diventi un maestro di un prodotto (Oracle, SQL Server, qualunque cosa) ci deve essere richiesta per questa conoscenza! Il DBA deve essere sottoposto ad ambienti e problemi complessi per aiutarlo a diventare più informato. Questo è fondamentalmente un mio rant, perché sono un DBA in un piccolo negozio e non faccio nulla che richieda più di 2 neuroni, penso che sto sprecando il mio tempo in questo lavoro. Voglio diventare uno sviluppatore.