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

11

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.

Isvara
la source
2
Eh bien, nous ne mettons pas d'instructions SQL dans le code. Cependant, TOUS les codes doivent être examinés par des personnes compétentes et bien informées.
CaffGeek
4
Le développement Web est essentiel. Le résultat est directement face au client (qui est votre roi), et le plus souvent, les données sensibles sont accessibles au serveur Web.
thiton
2
La question est, si toutes les requêtes ne sont pas passées par un DBA, comment définissez-vous ce qui doit et ne doit pas être passé par le DBA?
programmeur
6
@thiton: C'est une déclaration générale en supposant que TOUTES les applications Web sont publiques et sont les applications les plus importantes de l'organisation. Ce n'est tout simplement pas vrai. Parfois, les applications Web sont de troisième niveau ou inférieures (par rapport à d'autres applications). Certains ne sont utilisés que par de petites équipes internes. Sans savoir sur quoi travaille @ DanEllis, nous ne savons vraiment pas à quel point ce travail de développement Web est critique.
FrustratedWithFormsDesigner
2
Vous n'avez pas encore été mordu? Pensez à demander pourquoi cette procédure est en place ...

Réponses:

15

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.

bwalk2895
la source
-1 Une excellente réponse, mais malheureusement, la question portait sur l'examen par un dba après examen par un autre programmeur. Cette réponse est vraiment à la question "si tout le code doit être revu", mais ce n'était pas la question posée. Je ne vote pas trop ou par dépit, seulement quand ils répondent n'est pas une réponse à la question.
Michael Durrant
Exactement. Il s'agit d'un code qui a déjà été examiné dans son contexte . C'est important. Une requête isolée peut sembler inoffensive, mais placez-la dans une boucle et soudain, elle l'est moins.
Isvara
1
Existe-t-il des outils pour automatiser ce genre de choses? Je pense à un outil qui crée un plan d'exécution pour toutes les requêtes soumises, puis signale tout avec des analyses de table complètes ou un produit cartésien. Je doute qu'il puisse tout attraper , mais cela accélérerait probablement le temps de révision et il pourrait également être exécuté par les développeurs via un script, ou mieux s'il est exécuté automatiquement au moment de l'enregistrement du code.
FrustratedWithFormsDesigner
10

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.

Michael Durrant
la source
5

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é.

BZink
la source
6
Ce sont d'excellentes choses à mesurer. Pendant que vous y êtes, combien de temps est passé à réparer le code cassé autorisé en production? Combien d'heures faut-il aux ventes et au marketing pour trouver des clients pour remplacer ces clients perdus alors que votre site n'était pas fonctionnel, car une clause WHERE manquée a provoqué des analyses de table répétées? La révision du code a des coûts et des avantages, ne négligez pas non plus.
4
C'est pourquoi il est important de savoir combien de fois les modifications sont demandées / nécessaires par le DBA. La question dit explicitement que tout est révisé, sans exception. C'est ce type de politique générale qui a généralement plus de coûts que d'avantages. Je suis un grand partisan de la révision et des tests de code, mais cela ne signifie pas que chaque ligne est examinée ou testée. Nous sommes censés être des professionnels et il y a une différence entre le contrôle qualité et le baby-sitting.
BZink
4

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.

FormerIgnorantDeveloper
la source
Souhaitez-vous paraître plus saint que toi?
sevenseacat
2
@Karpie, au moins il a pris le temps de répondre en s'inspirant de sa propre expérience, plutôt que de faire un commentaire sarcastique sans valeur sur la réponse de quelqu'un d'autre comme Karpie.
Drew
2

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.

TMN
la source
2

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é.

Nathan Long
la source
1
Bien que ce soit un point de vue raisonnable, vous devez admettre que nous sommes très peu parmi nous aussi intelligents que nous aimerions le penser et que les pires délinquants sont les plus ignorants (presque par définition, pas ceux-ci), donc la façon dont vous évitez le problème est d'avoir une règle générale - tout le monde traite de la même manière
Murph
2
@Murph - absolument. Je pourrais faire une erreur. Mais je pouvais aussi prendre des pauses de 2 heures tous les jours. Est-ce que tout le monde devrait devoir suivre le temps passé dans sa salle de bain pour éviter cela? Devrions-nous avoir à signer des formulaires pour obtenir des trombones afin d'éviter le vol de trombones? À un moment donné, vous devez soit faire confiance aux gens, soit les renvoyer. Ma requête lente a un coût, mais il en va de même pour un processus d'examen fastidieux et fastidieux. Ce n'est que si de petites différences de performances de base de données coûtaient des millions (ou des vies) que j'accepterais ce genre de chose.
Nathan Long
1
Le problème est que vous n'êtes probablement pas le développeur moyen; et très probablement pas le développeur du problème. J'ai travaillé dans un endroit comme celui-ci, et c'était un peu nul. mais tu sais quoi? Ce sont nos administrateurs de base de données qui ont reçu l'appel au milieu de la nuit lorsque les requêtes ont éclaté, pas moi. Si ce sont eux qui sont tenus pour responsables, ils ont le droit de revoir le code dont ils sont responsables.
Telastyn
@Telastyn - le "développeur pas moyen" que je n'achète pas; Je dis toujours de ne pas embaucher de mauvais développeurs. Mais oui, si les DBA doivent recevoir l'appel, je sympathise un peu plus.
Nathan Long
@NathanLong its about context - dans les contextes dans lesquels vous travaillez, ce n'est probablement pas un problème, dans d'autres, il est clair qu'il a le potentiel d'être et l'une des façons d'éviter certains problèmes est d'avoir ce qui peut sembler être des règles stupides (bien que , comme le fait que j'utilise toujours {} dans mes instructions if, c'est fait dans un but précis). Son mauvais "parce que je n'aime pas ça et je pense que je suis en sécurité donc ça ne devrait pas s'appliquer à moi" est un argument discutable (la même logique est appliquée pour ignorer les limites de vitesse). Hmm, c'est argumentatif) -: Désolé.
Murph
2

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.

kemiller2002
la source
2

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.

Ian
la source
0

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.

Andrzej Bobak
la source
0

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.

softveda
la source