que font les programmeurs de bases de données?
Chaque fois que je lis sur les programmeurs Oracle, etc., je suis confus. Je ne sais pas exactement ce qu'ils font.
D'après ma compréhension, les programmeurs d'applications doivent développer la fonctionnalité de base. Les bibliothèques qu'ils utilisent peuvent aider au développement de l'interface graphique ou à la connectivité de la base de données, mais la fonctionnalité qui fait que cette application doit être programmée et qui rend chaque application différente (enfin certaines pourraient être des versions modifiées d'autres).
Dans cette relation, la programmation de base de données ne crée-t-elle pas essentiellement une table et ces tables ne sont-elles pas traitées en réponse aux instructions SQL qui sont émises par une application qui est généralement l'interface frontale? La création de table est-elle donc si importante?
Pour vraiment apprécier les programmeurs de bases de données, vous devez vraiment essayer vous-même - laissez-moi essayer de l'expliquer d'une autre manière.
Pour les mal informés, cela pourrait sembler dans le monde idéal les programmeurs d'applications ne font pas vraiment grand-chose - ils prennent les exigences et les processus tels qu'écrits par les analystes commerciaux et les traduire en code qui fait les enchères des programmeurs.
Bien sûr, toute personne ayant une expérience de la programmation saura que cela ne fonctionne pas ainsi - en ignorant pour le moment le fait que les exigences ne spécifient jamais le comportement de l'application dans les moindres détails, il y a un certain nombre de complications
- Les programmeurs doivent décider de la façon dont l'application doit être structurée.
- Traduire les exigences en quelque chose qu'un ordinateur comprend est souvent loin d'être anodin.
- Les programmeurs doivent être conscients des implications de performance des différentes approches possibles.
- Au fur et à mesure que les programmeurs acquièrent de l'expérience en utilisant la plate-forme de leur choix, ils deviennent plus compétents, fournissant un code de meilleure qualité à un rythme plus rapide.
(Bien sûr, c'est une liste considérablement réduite, j'essaie simplement de relever des points qui ont des parallèles dans le développement de la base de données.)
Eh bien, le développement de bases de données est à peu près le même - pour les personnes mal informées, cela semble assez simple, mais une fois que vous vous impliquez davantage, vous vous rendez compte des complications spécifiques du développement de bases de données:
- Ils décident de la structure de la base de données.
- Souvent, les requêtes plus complexes peuvent être loin d'être triviales à traduire par rapport aux exigences.
- Les développeurs de bases de données doivent se préoccuper des performances de la base de données.
- Ils doivent également se soucier du maintien de l'intégrité et de la disponibilité des données.
- Et tout comme les développeurs, les programmeurs de bases de données deviennent plus compétents dans tout ce qu'ils font à mesure qu'ils deviennent plus expérimentés.
Tout comme le développement d'applications est rempli d'embûches cachées (problèmes de threading, etc.), le développement de bases de données l'est aussi, et souvent les conséquences de tomber en panne de ces problèmes sont très graves (par exemple, perte de données ou potentiellement temps d'arrêt pour toutes les applications utilisant la base de données). .
Je pense que ce qui fait que les programmeurs pensent qu'il n'y a rien ("Un programmeur ne peut pas faire ça?"), C'est qu'il y a beaucoup de chevauchement entre les rôles, et ils nécessitent des compétences similaires. Je ne doute pas que quiconque a la capacité d'être un bon développeur a également la capacité d'être un bon programmeur de base de données compte tenu du temps et de l'expérience, mais personne ne devrait sous-estimer la valeur d'un expert en base de données expérimenté.
Les programmeurs de bases de données font beaucoup de choses. Ils conçoivent d'abord la structure de la base de données afin qu'elle fonctionne correctement avec le nombre d'enregistrements attendus. Des structures de conception qui fonctionnent correctement pour quelques milliers d'enregistrements peuvent rendre une base de données inutilisable pour quelques millions d'enregistrements. Ils doivent également s'assurer que les données conserveront leur intégrité dans le temps et que les données sont protégées contre les modifications non autorisées ou le vol. Ils doivent comprendre à fond la normalisation et quand se dénormaliser et pourquoi. Ils doivent comprendre les performances et comment garantir l'intégrité des données. Ils doivent comprendre la sécurité et comment empêcher le vol ou la modification malveillante des données.
Ils optimisent les requêtes de performances. J'ai modifié les requêtes qui prennent quelques minutes pour s'exécuter en millisecondes. J'ai modifié un processus qui a pris plus de 24 heures pour s'exécuter en moins de 30 minutes. Ils conçoivent et maintiennent des structures d'indexation qui équilibreront la vitesse des inserts et la vitesse des sélections.
Ils écrivent des requêtes complexes, en particulier des requêtes de rapport. Personnellement, j'ai écrit des requêtes de plus de 1 000 lignes en raison de la complexité de l'exigence. Ils devaient encore et ont couru rapidement.
Ils créent des entrepôts de données et les processus ETL associés pour les prendre en charge. Souvent, ils ont besoin d'écrire des processus pour importer des données d'autres sources et doivent trouver comment mapper les champs de la base de données de certains clients avec les leurs et ce ne sont jamais une correspondance étroite dans le type de données, la taille des données, les champs obligatoires, les valeurs de recherche, etc.
Ils doivent déterminer comment refactoriser au fur et à mesure que les exigences de la base de données changent sans nuire aux 100 000 000 enregistrements qu'ils ont déjà et sans arrêter complètement l'utilisation de la base de données. Les bases de données volumineuses peuvent impliquer des milliers de tables et de processus stockés et de fonctions définies par l'utilisateur. Comprendre une telle structure prend du temps et des compétences, tout comme comprendre ce qui sera affecté par les changements et comment.
Ils conçoivent des moyens d'auditer les données pour des raisons réglementaires et de récupération. Ils conçoivent ensuite des moyens de récupérer les données de ces tables d'audit. Ils recherchent des problèmes avec les données pour trouver si le problème provenait d'un bogue dans le processus d'importation, d'un mauvais fichier fourni par d'autres ou d'une mauvaise insertion/mise à jour de l'application, ou d'un accès non autorisé. Ils trouvent des moyens de corriger les mauvaises données lorsque les programmeurs d'applications laissent un trou ouvert aux pirates pour les attaquer.
Ils sont souvent impliqués dans les conversions de données d'un système à un nouveau système. Parfois, cela implique de déplacer des données d'un produit COTS vers un nouveau que la société vient d'acheter. Comme les importations décrites précédemment, ce sont des processus complexes qui peuvent prendre des mois à planifier et à exécuter et qui nécessitent des tests approfondis. Contrairement aux importations, le programmeur de base de données peut n'avoir aucun contrôle sur les structures de données disparates.
J'ai effectué un stage en tant que programmeur de base de données pour les données de fabrication d'une fabrique de plaquettes de 24 heures à la fin des années 90. Je ne sais pas à quel point mes tâches étaient typiques, mais la plus grande partie pour moi était lorsqu'un changement de codage de champ ou de schéma était nécessaire, je devais m'assurer que le changement était transparent à la production. Essentiellement, cela signifiait que je leur dirais de mettre à niveau leur application client, ce qu'ils feraient à un moment qui leur convenait, et il était prévu de revenir immédiatement avec les nouvelles modifications.
C'était beaucoup plus compliqué que je ne l'avais prévu. Les scripts de conversion et le logiciel client devaient être testés de manière approfondie. Souvent, deux ensembles de données sémantiquement identiques mais incompatibles devaient être maintenus en synchronisation jusqu'à ce que tout le monde soit inversé. Parfois, il était nécessaire d'effectuer le changement en plusieurs phases soigneusement planifiées afin de le rendre transparent. Il n'était pas rare de se préparer pendant des semaines à un basculement qui s'est produit essentiellement instantanément.
Si un programmeur de base de données fait bien son travail, il semblera aux observateurs que son travail est très facile. Je ne suis pas surpris que beaucoup de gens ne sachent pas vraiment ce qu'ils font.
C'est assez simple. Si vous avez entendu parler du modèle MVC, vous devriez connaître la différence entre vos contrôleurs et vos modèles. Par exemple, si vous écrivez un ERP alors imaginez que dans votre contrôleur vous dites simplement "retrieveCashFlow" à votre modèle et votre modèle appelle un programme stocké dans la base de données. Ce programme stocké prend soin de chaque joindre, filtrer, ordonner et ainsi de suite et vous obtenez les données traitées. Dans votre contrôleur, il vous suffit de bouger les choses ensemble.
Si vous avez des doutes sur les procédures stockées, vérifiez ceci: pourquoi utiliser des procédures stockées?
Autrement dit: les développeurs de bases de données écrivent des programmes stockés (procédures et fonctions) pour votre application afin de prendre en charge le M dans MVC (ou les logiques métier si vous n'utilisez pas mvc).
Oracle n'est pas seulement une base de données mais un environnement de programmation complet, comprenant des concepteurs de formulaires et de rapports. En tant que programmeur Oracle, vous programmez des applications utilisateur complètes. Le codage de base de données auquel vous vous référez serait souvent effectué par des administrateurs de base de données spécialisés (DBA).
Sybase, je pense, est un autre avec un environnement de programmation similaire.
D'autres bases de données peuvent se limiter à "simplement" permettre la définition et l'exécution de rapports, tandis que d'autres encore ne proposent aucun formulaire ni aucune facilité de conception/exécution de rapport.
Je dirais qu'un développeur de base de données est responsable d'un ou plusieurs des éléments suivants
- Conception, cela inclut la création (ou plutôt la définition de relations) de tables
- Optimisation, définition des index appropriés, choix des clés, choix des bons types de données
- Fonctions, écriture de fonctions utiles à utiliser dans les requêtes
- Procédures, écriture d'une logique d'application étroitement couplée à la couche de base de données.
- Création de fonctions de déclenchement pour répondre aux événements
- Produire les spécifications de ce qui précède.
Selon le SGBDR en question, il pourrait inclure des tâches telles que
- Création de rapports et de formulaires
- Création de flux pour l'importation/exportation de données
Jetez un oeil à cette liste des responsabilités