Chaque instruction SQL doit être examinée par un DBA - commun?

Je veux dire tout, pas seulement les changements de schéma. Même un simple SELECT sur une clé primaire ne peut pas entrer en production, même s'il a été révisé par d'autres développeurs (en contexte), sans examen DBA de chaque instruction, extrait du code et soumis avec la sortie EXPLAIN, détails de la fréquence à laquelle il sera appelé, etc., etc.

Si vous avez été dans un tel environnement, avez-vous trouvé que c'était un gain net ou un frein au développement? En tant que personne qui travaille avec des bases de données relationnelles depuis des années, je trouve que l'attitude "les développeurs ne peuvent pas faire confiance pour utiliser des bases de données" est injustifiée, et je suis curieux de savoir à quel point cette situation est courante. Pour ce que ça vaut, c'est juste pour le développement web, pas quelque chose de critique.

Lors de l'un de mes emplois précédents, j'ai (avec trois autres programmeurs) été chargé d'examiner chaque procédure stockée créée ou mise à jour avant sa mise en production pour environ 40+ programmeurs. En tant que critique, cela a été un véritable fardeau pour mon temps, mais dans l'ensemble, c'était encore nécessaire car avec cela, de nombreux développeurs commettront une erreur de temps en temps. Cela est dû au fait que nous avions des programmeurs off-shore qui ont écrit de très mauvaises instructions SQL (efficaces) et ils ont catégoriquement refusé d'apprendre (cette équipe a finalement été fermée).

Dans l'ensemble, nous avons recherché:

• Utilisation de l'index - la requête effectuait-elle une analyse complète de la table?
• Maintenabilité - la requête devait-elle être modifiée dans quelques semaines parce que quelque chose y était codé en dur? Et la requête est-elle lisible?
• Efficacité globale - une jointure interne pourrait-elle être remplacée par une existante? Est-ce que l'ajout d'une aide avec bloc?
• Problèmes de verrouillage - la requête verrouillerait-elle la base de données et empêcherait-elle les mises à jour? Cela s'est produit plus que je ne pense.

Plus souvent qu'autrement, la plupart des requêtes n'ont eu aucun problème et nous l'avons poussé. Mais chaque examen a pris entre 10 minutes et deux heures selon la requête. Une partie de moi a aimé l'idée de faire des critiques car elle empêchait l'appel téléphonique redouté à 2 heures du matin car certains rapports provoquaient un problème avec une autre application. Mais en même temps, je pensais que c'était un peu exagéré parce que nous sommes tous des adultes et que la personne qui écrit la requête devrait faire tout cela elle-même.

Je pense que les requêtes complexes devraient faire partie de la révision de code standard, mais n'ont pas besoin de passer par un DBA. Il n'est pas non plus nécessaire de passer en revue les simples instructions d'insertion / mise à jour / suppression. De plus, en tant que rédacteur d'une requête, vous devez savoir quand elle est devenue trop complexe et savoir quand demander un examen à un administrateur de base de données.

Mise à jour Dans mon tout premier travail, toutes les requêtes ont été écrites par des administrateurs de base de données et cela a été un tueur de temps majeur pour le développement. J'ai dû soumettre toutes les colonnes que je voulais, les tableaux où se trouvaient les colonnes et enfin mes critères de recherche. Même les instructions basiques d'insertion / mise à jour / suppression nécessaires pour passer par un DBA. Finalement, j'en suis arrivé au point où je pouvais écrire le SQL que je voulais, leur demander de l'examiner et d'apporter les modifications nécessaires, puis d'envelopper une procédure stockée autour de lui, mais cela ne faisait que quelques années. Cette entreprise particulière a embauché beaucoup de diplômés récents et c'est ainsi qu'ils ont veillé à ce que les nouveaux gars n'écrivent pas de requêtes qui ont tué la performance.

Cela dépend totalement de l'environnement, de l'industrie et de l'entreprise.

Quelques exemples:

• À la NASA, plusieurs niveaux de vérification et d'examen sont la norme. Le plus connu "aurait dû vérifier deux fois" était quand une sonde a été envoyée sur Mars et que les États-Unis ont fait des calculs en pieds, mais les Européens en mètres. La sonde a été perdue.

• Dans une startup sans DBA (courante ces jours-ci), il n'y aura pas de révision DBA et peut-être même pas de révision programmeur (par exemple, s'il n'y a pas d'autres programmeurs dans l'entreprise).

• Dans une entreprise dont le produit est un entrepôt de données de centaines de millions de lignes, s'assurer que les requêtes sont efficaces et correctes peut être des problèmes clés au cœur de l'entreprise qui doivent être vérifiés.

Une entreprise dont le produit principal est un site Web principalement statique avec un petit nombre d'interactions avec la base de données, peut considérer la base de données et son efficacité comme moins pertinentes. Il se peut que l'entreprise choisisse de dépenser son "budget" de révision sur les pages statiques considérées comme les plus critiques.

Je n'ai jamais travaillé dans un environnement comme ça, je suis sûr que je détesterais ça. Une idée vient à l'esprit pour commencer à garder une trace de certaines mesures à ce sujet ...

• Combien de temps un développeur passe-t-il à retirer SQL du code et à le préparer pour être soumis à un administrateur de base de données
• Combien de temps le DBA prend-il pour revoir le sql?
• À quelle fréquence les modifications sont-elles demandées par le DBA? Ventilé par
  type de requête ?

Garder une trace de cela pendant un petit moment montrerait probablement à quel point c'est un frein par rapport à son efficacité.

La plupart des développeurs ignorent complètement les bases de données. Ils ne sont même pas conscients de leur ignorance. J'étais moi-même un développeur ignorant.

Les développeurs vivent dans un monde d'optimisation, c'est le mal. Cet état d'esprit ne fonctionne pas lorsque vous effectuez des opérations sur un disque. Cet état d'esprit ne fonctionne pas lorsque vous choisissez un type de données 8 fois plus grand qu'il ne doit l'être, ce qui fait que l'index est 8 fois plus grand qu'il ne doit l'être afin qu'il ne puisse plus tenir en mémoire. Cet état d'esprit ne fonctionne pas lorsque vous programmez contre une API générique qui met à jour de manière redondante toutes les colonnes d'une table (non merci les beans Java).

Ils ne savent pas ce qu'est un scan de table complet. Ils ne savent pas comment traiter les données en une seule opération au lieu d'ouvrir un curseur. Pire qu'un curseur, ils interrogeront les données, puis les traiteront ligne par ligne dans un sens et dans l'autre vers la base de données lorsqu'une simple mise à jour en plain-jane suffira. Résultat: des performances HORRIBLES.

Ils ne connaissent pas les conséquences graves des rapports sur les grandes tables. Le besoin de rapports nécessitera peut-être la création d'un schéma en étoile et d'un flux de données. Votre développeur moyen interrogera simplement les tables existantes et se demandera pourquoi il faut 3 heures pour exécuter la requête (c'est un vrai chiffre).

Les connaissances de votre développeur moyen suffiront pour les applications CRUD «moyennes» où un utilisateur modifie simplement un enregistrement. Cela ne suffira pas une fois qu'ils sortiront de la bulle de Ruby-on-Crack et entreront dans le monde réel.

Dépend de la taille de la base de données et de son partage entre plusieurs applications. Souvent, l'équipe DBA aime savoir quelles requêtes seront exécutées afin de s'assurer que les index appropriés sont en place, ou alors de savoir qui avertir si elle doit partitionner une table. Et ils ont tendance à être un peu meilleurs que le développeur moyen pour lire les plans d'exécution des requêtes et repérer les endroits où des conseils pourraient être spécifiés pour améliorer les performances. C'est également une chance pour eux de savoir que certaines requêtes à fort impact seront publiées dans la prochaine version, afin de pouvoir collecter différentes statistiques pour l'optimiseur.

Je n'ai pas travaillé dans un tel environnement, pas plus que moi.

Il y a une différence entre le travail d'équipe et une bureaucratie hostile. En tant que développeur, j'aimerais avoir une entrée DBA sur les requêtes difficiles. Mais je sais quand demander de l'aide.

Si je ne suis pas assez compétent pour les SELECTrequêtes simples , je devrais être viré.

J'ai vu cela à deux endroits différents. C'est génial en théorie, mais je l'ai rarement vu être efficace. Voici pourquoi. Premièrement, si vous avez une équipe de DBA (ou d'autres personnes), j'ai généralement constaté que la personne la moins compétente ou la moins aimée du groupe subit le gros du travail de révision. Pourquoi, dites-vous? C'est parce que personne d'autre ne veut le faire, et tout le monde est occupé à faire d'autres choses qui sont probablement plus urgentes. Jamais vu un DBA s'asseoir et dire: "Homme, tout fonctionne parfaitement; je peux simplement m'asseoir et surfer sur le net. J'aimerais avoir quelque chose à faire." Moi non plus, du moins pas les bons. Ils sont aussi occupés ou occupés que tout le monde. Cela signifie que la personne la moins capable est le plus susceptible de procéder à l'examen, et c'est exactement la personne que vous ne voulez pas faire. Le code que vous voulez revoir est le code vraiment très dur que les gens regardent et le font passer pour une sorte de magie noire. Les administrateurs de bases de données juniors ou tout simplement mauvais, ne pourront jamais saisir les subtilités du fonctionnement d'une requête vraiment difficile. Rarement, comme jamais, quelqu'un dit jamais: "Homme, je n'ai pas pensé à sélectionner une seule ligne dans une table en utilisant la clé primaire! Merci DBA, vous êtes une bouée de sauvetage." Donc, dans ce scénario, tout ce que vous faites, c'est créer beaucoup de travail pour peu de valeur. t pensez à sélectionner une seule ligne dans une table en utilisant la clé primaire! Merci DBA, vous êtes une bouée de sauvetage. "Donc, dans ce scénario, tout ce que vous faites, c'est créer beaucoup de travail pour peu de valeur. t pensez à sélectionner une seule ligne dans une table en utilisant la clé primaire! Merci DBA, vous êtes une bouée de sauvetage. "Donc, dans ce scénario, tout ce que vous faites, c'est créer beaucoup de travail pour peu de valeur.

Deuxièmement, c'est tout simplement plus de travail pour le groupe DB. Ce qui va probablement se produire même s'ils examinent d'autres choses, c'est qu'ils vont y jeter un coup d'œil rapide et que quelque chose va manquer. Ce sont des gens très occupés et la révision du code prend beaucoup de temps. En vérité, il n'est pas juste qu'ils soient chargés de cela, car c'est une excuse pour que tout le monde soit paresseux et les utilise comme sortie, ce qui est finalement ce qui se passe. Quelque chose se casse dans la production, et le développeur souligne rapidement: "Eh bien, le DBA l'a examiné." Maintenant, c'est vrai tout le temps, non, mais c'est vrai une partie du temps et souvent des personnes qui ont besoin de faire réviser leur code. Vous avez donc enterré le DBA avec du travail supplémentaire et forcé cette personne à être responsable des erreurs de quelqu'un d'autre, alors que cette personne ne le fait probablement pas.

La seule façon de vraiment résoudre le problème est d'avoir des gens qui savent écrire du code SQL. Devraient-ils obtenir de temps à autre les commentaires des administrateurs de base de données? Bien sûr qu'ils le devraient, mais j'ai toujours trouvé, si vous n'avez pas le temps de bien faire les choses la première fois, quand allez-vous trouver le temps de le réparer.

J'ai travaillé dans ce genre d'environnement. Tous les changements au système ont été examinés par des pairs appropriés. Pour moi, cela signifiait simplement que je devais planifier à l'avance et soumettre mes modifications quelques jours à l'avance. SQL est allé aux administrateurs de base de données qui finiraient par mettre le SQL en production.

Mon SQL est généralement bien, ils ont attrapé quelques erreurs stupides. Cela semble trop bureaucratique au début, mais je travaille dans la finance. Vous avez vu ce qui se passe (si vous êtes au Royaume-Uni) il y a quelques mois lorsqu'une grande banque ici a raté une mise à niveau de routine et a foiré toutes les transactions conduisant à des millions (au moins des centaines de milliers) de personnes incapables d'obtenir à leur argent.

J'irais même plus loin. Je vérifierais le code environnant et verrais comment les variables sont transmises à la requête. C'est souvent pour voir comment les développeurs exposent leur application à des attaques par injection sql en raison de leur manque de connaissances de base ("cela ne peut pas être piraté" de fausses hypothèses).

Les développeurs inexpérimentés peuvent également faire glisser la base de données à genoux avec une mauvaise utilisation de l'ORM ou une requête qui est loin d'être optimale.

Dans le projet le plus récent sur lequel je travaille, aucun développeur frontal n'est autorisé à accéder directement à la base de données. Ils soulèvent une demande pour une fonction renvoyant un ensemble de données donné et les développeurs principaux le préparent pour eux. Cela fonctionne assez bien, les développeurs frontaux écrivent l'interface utilisateur et traitent les données fournies par les fonctions écrites par les développeurs backend.

Dans notre équipe de développement, il y a une sous-équipe de 4 développeurs de bases de données expérimentés dans la plate-forme SGBD que nous utilisons. Ils écrivent tous les SQL ou au moins les révisions et apportent des modifications pour répondre à leurs normes de codage tout SQL écrit par les développeurs .Net. Ils font partie de l'équipe projet. Les DBA de production appartiennent à un département complètement différent et leur travail est opérationnel. Ils ne passent pas en revue notre code SQL ou notre schéma et même le déploiement est scripté, ils ne font qu'exécuter le script. Le plus qu'ils aident est dans le réglage des performances.