Dans quelle mesure un administrateur de base de données a-t-il besoin de connaître les langages de programmation au niveau du système ou des applications (par exemple .NET ou PHP) en plus de "juste SQL"?
Aux fins de cette question, aucune version spécifique de la norme SQL n'est prise en compte pour cette réponse (SQL ANSI 86, SQL ISO 87, SQL: 2008) car la question concerne les langages de bureau ou de serveur en dehors du domaine de SQL.
Réponses:
Ça dépend.
Dans une grande boutique, peut-être pas parce que vous avez des milliers de serveurs à entretenir et que vos outils sont fournis. Dans une petite boutique, vous aurez probablement besoin de plus de connaissances car vous avez un mandat plus large.
Les langages de script (PowerShell, cmd.exe par exemple) sont toujours utiles pour la surveillance, le déploiement, etc. J'ai souvent eu quelques scripts Perl que je devais maintenir (à peu près). Ensuite, il y a les packages ETL assortis que vous devriez connaître.
Cela dit, la plupart des administrateurs de bases de données (que je connais) seraient en mesure d'écrire des choses CLR de base ou de bien connaître PL / SQL. Pour moi, la ligne de démarcation est de connaître les modèles ou l'architecture plus larges de .net ou Java. Je n'en ai pas besoin en tant que développeur DB ou DBA. De la même manière que .net ou PHP ou Java Monkeys ne comprennent pas la conception, l'architecture ou le code de la base de données aussi bien que moi.
Personnellement, j'ai décidé d'arrêter de courir après la dernière ou la meilleure langue cliente il y a des années et de me concentrer sur le travail de base de données. Cela ne fait pas de moi un "non programmeur": j'aurais besoin de le réapprendre si je le devais.
Je savais que les administrateurs de base de données s'en sortaient avec peu ou pas de compétences en programmation, mais tous les administrateurs de base de données que j'ai jamais considérés comme bons avaient au moins des compétences de programmation raisonnables. Un ou deux dont je peux penser avaient des antécédents de développement substantiels et étaient assez bons développeurs à part entière. Il y a une bonne quantité d' outils open-source écrits par des personnes qui travaillent comme DBA dans leur travail de jour et IIRC le gars qui a écrit TOAD travaillait comme DBA.
Selon le rôle, vous pourriez vous retrouver à écrire ou à régler des requêtes, à écrire des scripts pour automatiser des tâches ou à consulter sur la conception d'applications. Dans certains cas, vous pouvez simplement vous occuper d'un groupe de serveurs via OEM ou un autre outil de surveillance.
Les environnements de développement «d'entreprise» modernes tels que .Net ou Java sont suffisamment complexes pour qu'un développeur puisse faire carrière simplement en se spécialisant dans ces domaines. En tant que DBA, en particulier dans le domaine du développement, avoir une connaissance pratique de C # ou de Java peut ne pas nuire, mais vous ne passerez probablement pas beaucoup de temps à les coder.
Vous obtiendrez probablement plus de kilomètres quels que soient les outils de script utilisés sur votre plate-forme, bien que de nombreux systèmes exposent des API de service .Net, Java, COM ou Web. Si vous devez coder quelque chose par rapport à ces API, vous aurez besoin d'au moins une connaissance pratique de base de quelque chose qui peut consommer cette API. Cependant, des compétences avancées en architecture d'application ne sont généralement pas nécessaires pour ce faire.
Certains développeurs auront de solides compétences en bases de données, mais la peur irrationnelle des bases de données est assez courante dans les cercles de développement. De nombreux développeurs ne parviennent pas non plus à vraiment comprendre le paradigme des «opérations définies» qui sous-tend SQL. En tant que DBA Dev, vous pouvez vous retrouver face aux conséquences de cela, et peut-être avoir à intervenir dans le code de procédure stockée pour résoudre les problèmes de performances.
L'ETL et les outils entourant la base de données peuvent également relever du DBA. J'ai vu pas mal de rôles DBA annoncés qui semblaient impliquer une quantité importante de travail de développement back-end. Ce sera plus courant dans les petites entreprises. Une affiche récente souhaitait intégrer des mesures personnalisées dans Oracle Enterprise Manager, qui dispose d'une API de plug-in pour ce faire. Il est assez courant de voir des exigences comme celle-ci apparaître, et essentiellement la seule façon d'y parvenir est d'écrire du code de collage.
Il existe de nombreux «Tools Guys» travaillant dans l'informatique et ils peuvent faire un travail utile malgré le parochalisme. Cependant, lorsque les outils s'épuisent, souvent la seule façon de faire quelque chose est d'écrire un peu de code pour le faire. C'est là que les compétences en programmation séparent les hommes des garçons.
Je dirais pas typiquement, mais ça ne fait jamais de mal. SQL Server est suffisamment grand pour que je ne pense pas qu'une seule personne puisse maîtriser l'ensemble du produit. Je suis DBA depuis SQL Server 4.2, et je me considère comme un expert dans la plupart des domaines, mais j'avoue que je ne serais pas en mesure d'écrire une requête MDX sans Google à portée de main à chaque étape du processus.
Ce que j'essaie de dire, c'est que vous ne pouvez pas être un expert en tout. Être un très bon DBA signifie que vous devriez être excellent en T-SQL, mais que vous n'êtes probablement pas très bon en .NET, ou du moins pas aussi efficace que d'autres qui peuvent concentrer leur temps sur .NET.
Powershell est bon à savoir, tout comme les tenants et les aboutissants du SSIS. En dehors de cela, laissez les autres langages de développement aux développeurs.
D'après mon expérience, bien que la plupart des administrateurs de bases de données aient une sorte de formation en développement, ils ne sont pas du tout tenus d'écrire du code. Les très bons DBA avec lesquels j'ai travaillé ont une connaissance approfondie d'une variété de sujets, y compris les scripts shell, les systèmes d'exploitation et les connaissances spécialisées des applications (ex: PeopleSoft).
J'ai eu un instructeur d'administration de base de données à l' école grad qui nous a donné une liste de questions que tout bon (Oracle) DBA devrait être en mesure de répondre: (Je vais poster quelques - uns des faits saillants de la liste des 40 ou si)
(Oracle) Le besoin de DBA de connaître ces choses pour être efficace. La plupart des développeurs que je connais (qui codent contre Oracle) auraient du mal à répondre correctement à un ou deux d'entre eux.
Si vous êtes le DBA, vous travaillez probablement dans les domaines de la performance et de la sécurité (entre autres). Cela pourrait impliquer le profilage et l'aide à l'optimisation des applications clientes sur lesquelles les développeurs travaillent. Ainsi, cela ne ferait certainement pas de mal de connaître les bases des langues que les développeurs utilisent et comment s'interfacer avec le serveur de base de données. Pour SQL Server, c'est probablement .NET. Pour MySQL, probablement une combinaison de php ou java.
Par exemple, si le serveur subit des pressions pour les threads clients, il peut être utile d'informer les développeurs qu'ils doivent utiliser des instances singleton pour leurs ObjectDataSources afin qu'ils puissent réutiliser une seule connexion à la base de données. Et assurez-vous également qu'ils utilisent correctement les requêtes paramétrées pour limiter l'injection SQL. Des trucs comme ça.
Vous ne ferez aucune programmation dans le sens de développer des applications clientes si vous êtes strictement un DBA, mais vous devez savoir comment elles fonctionnent (en général).
Eh bien, voyons, Oracle utilise PL / SQL qui est vraiment similaire à Pascal (un langage qui était utilisé pour produire du code d'application de bureau mais qui est tombé ces dernières années, et les développeurs ont dérivé vers Delphi, dont certains sont partis de là vers .NET), et Oracle prend désormais également en charge Java pour certaines activités. Puisqu'un DBA Oracle doit connaître tous les aspects du système pour être bien apprécié, je dirais que connaître Pascal et Java serait une exigence.
TSQL a la capacité d'écrire du code managé .NET (CLR) pour certaines des fonctionnalités de Sql Server, et par conséquent, un bon DBA aurait probablement besoin de le savoir (mais il n'est pas toujours capable d'être utilisé dans les anciennes versions, donc beaucoup des administrateurs de base de données ont tendance à se détourner de cet ensemble de fonctionnalités dans mon expérience).
Voilà donc les deux grands, et ceux auxquels la plupart des gens se réfèrent lorsqu'ils demandent comme vous le demandez. Je ne connais pas tous les autres moteurs pour savoir ce qu'ils font et ne prennent pas en charge, mais je sais que beaucoup d'autres ont également une intégration de langage en plus de SQL.
Je suis assez convaincu que seuls les grands magasins avec de grandes applications ont une demande pour un DBA sans programmation, car les petits magasins avec des bases de données simples peuvent s'en tirer avec le développeur / DBA jack-of-all-trades. Pour qu'un DBA devienne maître d'un produit (Oracle, SQL Server, peu importe), il faut une demande pour ce savoir-faire! Le DBA doit être soumis à des environnements et à des problèmes complexes pour l'aider à devenir plus compétent. C'est essentiellement une diatribe de moi, parce que je suis DBA dans un petit magasin et que je ne fais rien qui nécessite plus de 2 neurones, je pense que je perds mon temps à ce travail. Je veux être développeur.