que font les programmeurs de bases de données?


14

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 le frontal? La création de table est-elle donc si importante?

Réponses:


18

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 personnes mal informées, il peut sembler que 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 traduisent en code qui fait les offres des programmeurs.

Bien sûr, toute personne ayant une expérience de la programmation saura que cela ne fonctionne pas comme cela - ignorant pour le moment 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
  • À 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)

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 être soucieux de maintenir l'intégrité et 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 penser aux programmeurs qu'il n'y a rien ("Un programmeur ne peut pas faire ça?"), C'est qu'il y a beaucoup de chevauchements entre les rôles, et ils nécessitent des compétences similaires - j'ai il ne fait aucun doute 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é.


Merci pour la réponse (j'avais abandonné tout espoir d'en obtenir un)! La raison pour laquelle j'ai demandé cela, c'est que moi, en tant que "programmeur d'application", j'ai conçu une petite base de données dans msaccess pour faire quelque chose pour mon projet et cela ne semblait pas beaucoup de travail, mais en tant que programmeur, bien sûr, je ne fais pas de chose t "facile". Mais je n'ai toujours pas la perspective nécessaire pour comprendre cela. Je veux dire, à quel point une base de données pourrait-elle être différente d'une autre? Comme aucun développeur d'application "écrit" le code de gestion de fichiers mais utilise des bibliothèques, n'y a-t-il pas de modèles / bibliothèques prêts à utiliser pour la conception de base de données? Ou la programmation dbase est-elle en réalité une administration dbase?

Un programmeur typique ne ferait-il pas cela aussi? Je suppose que j'ai déjà travaillé dans une trop petite organisation pour observer une utilisation exclusive d'un programmeur de base de données, car le développeur de l'application est généralement celui qui conduit le train, pour ainsi dire. Il sait ce qu'il veut et le conçoit généralement lui-même.
Brian

1
D'après mon expérience, certaines actions commerciales nécessitent des équipes d'experts DBA. La plus récente dont j'ai entendu parler était une fusion entre Coca-Cola et Minute Maid. Leurs bases de données (et elles en avaient beaucoup) ont dû être fusionnées, et Minute Maid n'a pas été conçue de la même manière que Coca-Cola avait la leur et ceci, cela et l'autre chose. Ils ont planifié et testé cette fusion pendant six bons mois avant de tirer une nuit blanche pour la réaliser. Avoir un DBA autonome n'est pas nécessairement requis dans une petite entreprise, mais dans les grandes, leurs équipes deviennent absolument nécessaires pour la satisfaction du client.
Mike S

Cela dit, dans les petites entreprises (<50 personnes) ayant au moins un (de préférence deux ou trois) DBA autonomes, c'est super, super sympa d'avoir en ce qui concerne les développeurs d'applications. Cela et un personnel informatique dédié pour réparer les ordinateurs, mais c'est une autre histoire.
Mike S

2
@ 0A0D, et tous trop souvent 6 ans plus tard, quand il y a un milliard ou plus d'enregistrements dans les tables et lorsque tout le désordre est incroyablement lent, ils embauchent un expert de la base de données pour réparer le désordre qui n'aurait jamais dû être conçu par un programmeur d'application. Les bases de données sont extrêmement difficiles à refactoriser et doivent être conçues pour les performances dès le départ, ce que trop peu de programmeurs d'applications semblent comprendre. Ils ont également tendance à concevoir en fonction de ce dont l'interface utilisateur a besoin et non de ce dont la base de données a besoin et donc d'omettre les contrôles internes et les contraintes d'audit et d'intégrité des données, etc.
HLGEM

12

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 maintiendront 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 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 de 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 vers un nouveau système. Parfois, cela implique de déplacer des données d'un produit COTS vers un nouveau que l'entreprise 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.


6

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 cliente, ce qu'ils feraient à un moment qui leur conviendrait, et il devrait 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.


2

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, 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 en charge chaque jointure, filtrage, commande, etc. et vous récupérez les données traitées. Dans votre manette, il vous suffit de faire 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).


2

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, alors que d'autres encore ne proposent aucun formulaire ni aucune facilité de conception / exécution de rapport.


1
"Oracle n'est pas seulement une base de données mais un environnement de programmation complet ... D'autres bases de données peuvent se limiter à" simplement "permettre la définition et l'exécution de ..." Cela, je ne le savais pas. Maintenant, c'est logique.
Thomas

SQL Server est le même. Outre les procédures stockées, les packages SSIS permettent la programmation visuelle, l'appel à d'autres codes existants, l'écriture de programmes vb.net ou c # .net, et bien plus, le tout dans un IDE. Je n'ai pas utilisé SSRS, mais je pense que c'est similaire. Il existe une tonne de programmation, et un programmeur de base de données doit connaître de nombreux outils, langages et processus différents.
jeudi jeudi

2

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 œil à cette liste de responsabilités

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.