Vérifiez ce qu'il a écrit

Une procédure, pas un ressenti

Auditer une requête n'est pas une ambiance. Il s’agit d’une liste de contrôle que vous exécutez à chaque fois dans le même ordre, jusqu’à ce qu’elle devienne automatique. L’ordre compte : les chèques bon marché qui invalideraient tout le reste passent en premier. Voici l’ordre à vérifier, et l’ordre à conserver pour la suite de votre carrière.

1. Grain. Que représente une ligne du résultat ? Est-ce que cela correspond à ce que vous avez demandé ?
2. Joindres. Pour chaque jointure, est-ce une à une ou une à plusieurs ? S'il s'agit d'un à plusieurs, est-ce que quelque chose qui ne devrait pas l'être est additionné après ?
3. Filtres. Quelles lignes ont été exclues ? Les exclusions sont-elles celles que vous avez acceptées ? Existe-t-il un !=, un IN ou un NOT IN qui supprimera les NULL ? Une liste d’inclusion est aussi dangereuse qu’une liste d’exclusion.
4. Colonnes. Chaque colonne est-elle celle à laquelle vous parliez ? Vérifiez d'abord les colonnes de revenus et de dates, car chacune a généralement plus d'un candidat plausible.
5. Dates. La plage est-elle à moitié ouverte (>= start AND < end), ou BETWEEN compte-t-elle deux fois ou supprime-t-elle une limite ? Est-ce même la bonne colonne de date ?
6. NULLs. Un agrégat sur une colonne avec des NULL ? Un AVG dont vous n'avez pas vérifié le dénominateur ?
7. Deuxième méthode. Calculez le numéro du titre d'une manière différente et comparez.

Le point 7 est celui que les gens pensent avoir fait alors qu’ils ne l’ont pas fait. Écrire une deuxième requête qui est en accord avec la première ressemble à une vérification. Souvent, cela ne prouve rien.

Un testeur a écrit une deuxième requête, elle était en accord avec la première au centime près, et il a marqué le numéro comme étant vérifié. Mais les deux requêtes utilisaient la même clause WHERE et le même INNER JOIN. La seule chose qu’ils ont prouvée, c’est que SUM est déterministe. Tous deux avaient tort de la même manière, et l’accord ne prouvait rien.

Alors appliquez un test. Pour chaque hypothèse de la première requête (le filtre, le type de jointure, la colonne de revenus, la limite de date) demandez si la deuxième requête fait la même hypothèse. Si cela les fait tous, c'est la même requête dans des mots différents. Une véritable deuxième méthode change au moins une chose : comptez de l'autre côté de la jointure, agrégez à un grain différent, supprimez le filtre et soustrayez, ou rapprochez-vous d'un total que vous avez calculé à la main.

Votre tâche

Exécutez les sept points sur la requête de la dernière leçon, queries/agent_v1.sql. Copiez le modèle de queries/audit-template.md dans queries/audit_v1.md et remplissez-le - une phrase par élément de la liste de contrôle, en disant ce que vous avez vérifié et ce que vous avez conclu. Pour la deuxième méthode, assurez-vous que votre chèque modifie au moins une hypothèse par rapport à l'original ; s'il réutilise le même filtre et la même jointure, c'est la même requête avec des mots différents et cela ne prouve rien.

Vérifiez votre compréhension

• Que représente une ligne du résultat et correspond-elle à la demande ?
• Lequel des sept contrôles, le cas échéant, a révélé un problème ?
• Votre deuxième méthode modifie-t-elle au moins une hypothèse par rapport à la première ? Nommez l’hypothèse qu’elle change.

Faites-le avec votre agent

Dites next lesson et votre agent vous apprend cela, vous pose ces questions, puis définit la tâche ci-dessus. Faites-le à la main, puis dites review my work - il vérifie votre travail par rapport à une rubrique et vous indique ce qu'il faut corriger ou marque la leçon terminée.