Contacter l'assistance

Nous répondons par e-mail, en général sous deux jours.

Pour prévenir les abus, Google reCAPTCHA vérifie cet envoi ; des données sont transmises à Google. Le script n'est chargé qu'à l'ouverture de ce formulaire.

← Tous les articles

Les colonnes que rien n'écrit

La table principale des compteurs compte ici 166 436 lignes et plusieurs colonnes qui ont l'air d'avoir de l'importance. Trois d'entre elles sont lastdomain, firstdomain et userdomain. Elles contiennent des données :

lastdomainnon vide dans 15 525 lignes
firstdomainnon vide dans 15 457 lignes
userdomainnon vide dans 2 982 lignes

Rien ne les écrit. Aucune instruction du dépôt ne fixe l'une des trois. Les valeurs viennent de la génération précédente de ce service, figées à ce qu'elles étaient quand elle a cessé de tourner, et toute ligne créée depuis est vide.

Pourquoi c'est pire qu'une colonne vide

Une colonne entièrement vide est manifestement morte. Personne ne construit dessus, personne n'en tire de rapport, personne ne passe un après-midi à se demander ce qu'elle signifie.

Une colonne remplie pour 9 % des lignes est un piège. Elle ressemble à un champ parfois rempli et parfois non — ce qui est parfaitement ordinaire pour une colonne. Qui la trouve en conclut raisonnablement qu'il existe une règle décidant quand elle est renseignée, et se met à chercher la règle. Il n'y en a pas.

Et les valeurs périmées ne sont pas rangées sur des lignes dormantes où elles ne feraient aucun mal. Parmi les lignes portant un lastdomain, 1 613 appartiennent à des compteurs encore mis à jour cette année. Un compteur vivant avec un domaine noté il y a dix ans ressemble exactement à un compteur vivant avec un domaine actuel.

Pire, les données sont plausibles. Ce sont des domaines, ils ressemblent à des domaines de compteurs, et une requête qui joint dessus renvoie des lignes. Elle répondrait à une question sur un web qui a continué sans elle.

Comment le savoir vite

Cherchez les écritures, pas le nom. Un nom de colonne apparaît dans des listes SELECT, des exports de schéma, d'anciennes migrations, des commentaires — ce qui ne prouve rien. Ce qui tranche, c'est de savoir si un INSERT ou un UPDATE la mentionne. Cette recherche prend une minute et elle est concluante d'une manière dont la lecture autour du code ne l'est pas.

La seconde vérification, ce sont les données elles-mêmes : si la ligne la plus récente portant une valeur a des années, la colonne est un fossile, quoi que le code semble dire.

Pourquoi elles sont encore là

Supprimer une colonne est peu coûteux mais pas gratuit. Chacune de ces lignes appartient au compteur de quelqu'un, certains tournant sans interruption depuis 2006, et l'opération sûre avant un changement de schéma sur une telle table est une sauvegarde que vous avez réellement restaurée une fois, pas seulement produite. Tant que cela ne vaut pas la peine en soi, trois colonnes inutilisées ne coûtent que de la confusion.

Elles sont donc documentées à la place. Il n'y a pas d'endroit évident pour cette note — le schéma de cette base n'existe que dans la base en fonctionnement, dans aucun fichier du dépôt — alors elle est allée là où quelqu'un trébuchera réellement dessus : dans la classe qui lit une ligne de compteur, juste là où ces colonnes passent. Une note dans un fichier que personne n'ouvre n'est pas de la documentation. Elle ne transforme un piège en note de bas de page que si elle est sur le chemin.

Publicité