Ce que vous pouvez et ne pouvez pas déléguer

Pannes bruyantes et pannes silencieuses

Vous savez depuis la dernière leçon ce qu'est une requête : une question écrite en SQL, envoyée à une base de données et répondue par des lignes. La distinction que fait l'ensemble du cours réside dans les deux manières dont une requête peut échouer.

Une erreur de syntaxe – une faute de frappe, une colonne mal orthographiée, une virgule manquante – vous coûte une minute. La base de données refuse d'exécuter la requête et vous indique où se situe le problème. C'est un échec retentissant : il s'arrête, il se plaint et vous le réparez avant que quiconque ne voie un numéro. Une requête qui s’exécute, renvoie un nombre et est discrètement fausse peut coûter un quart. C’est un échec silencieux : il réussit et renvoie la mauvaise réponse, et rien ne vous prévient. Le numéro apparaît dans un rapport, quelqu'un agit en conséquence et l'erreur fait surface des semaines plus tard.

Les pannes bruyantes sont bon marché car l'outil les trouve pour vous. Les échecs silencieux coûtent cher car seule une personne capable de lire la requête les détectera. Devenir cette personne est le but de ce cours.

Un agent écrit la syntaxe SQL correcte plus rapidement que vous. Sur les schémas de manuels scolaires - un schéma est la présentation complète d'une base de données : quelles tables existent et quelles colonnes chacune possède - les modèles actuels répondent correctement aux questions en anglais simple dans plus de 90 % du temps. Sur les schémas d'entreprise réels, avec des centaines de tables et de colonnes dont les noms induisent en erreur, les mêmes modèles de pointe chutent à environ 20 %. La lacune n’est pas la syntaxe. Les modèles produisent toujours du SQL valide. L’échec est sémantique : quelle colonne contient les revenus souhaités, quelles lignes laisser de côté et quelles jointures doublent discrètement le total.

Un agent ne peut pas savoir que net_price est la colonne de revenus et que unit_price ne l'est pas, à moins que quelque chose ne le lui indique. Il ne peut pas savoir qu'une commande peut avoir un statut manquant ou que deux tables joignent une ligne à plusieurs. Ces faits vivent dans votre tête, dans les données et dans les fichiers que vous remettez à l'agent. C'est pourquoi vous auditez le SQL que vous n'avez pas écrit, même lorsqu'il s'exécute.

La même distinction, travaillée à travers un exemple de cet ensemble de données, est fournie dans le projet docs/failure-modes.md : vous aurez ce fichier sur votre ordinateur après la configuration de la prochaine leçon. La section 2 vous demande d'écrire SQL à la main avant de déléguer quoi que ce soit, non pas parce que taper SQL est le travail, mais parce que vous ne pouvez pas auditer ce que vous ne pouvez pas lire.

Vérifiez votre compréhension

• Quelle est la différence entre une panne bruyante et une panne silencieuse ?
• Pourquoi une requête qui s'exécute avec succès doit-elle encore être révisée ?
• Nommez une chose qu'un agent ne peut pas savoir à propos de vos données à moins que vous ne le lui disiez.

Faites-le avec votre agent

Il s'agit d'une leçon conceptuelle - rien à construire pour l'instant. Dites next lesson et votre agent vous guidera et vérifiera que vous avez suivi avec quelques questions. Puis répétez next lesson pour continuer.