Les colonnes à ne pas oublier pour vos tables SQL

Dans l’apprentissage du langage SQL on apprend rapidement qu’une clé primaire avec identifiant unique est très important pour reconnaître une ligne et la modifier plus facilement. Avec plus d’expérience on apprend l’utilité d’autres colonnes tout aussi importantes à implémenter. Cet article présente des colonnes qu’il faut penser à implémenter pour ne pas le regretter plus tard.

Modélisation des données fictives d’une table utilisateur

Pourquoi s’intéresser à ces colonnes dès maintenant ?

Oublier d’enregistrer une information aussi important que la date d’ajout de la ligne peut poser de grands problèmes pour savoir par exemple à quel moment un utilisateur s’est inscrit ou à quel heure il y a eu une tentative de piratage des données. Certaines données doivent être prévues au plus tôt car elle ne peuvent pas être ajoutée de façon rétro-active.

Liste des données importantes

Voici une liste non-exhaustive de quelques données qu’il est judicieux d’enregistrer dans la plupart des tables d’une base de données :

• Un identifiant unique, souvent intitulé “ID”, qui sert de clé primaire (cf. PRIMARY KEY)
• Un élément aléatoire lié à la sécurité, tel qu’un “hash”, un “salt” ou une “key”. Il peut s’agir d’une chaîne aléatoire encodée en MD5 (ou SHA1) par exemple à utiliser en complément de l’identifiant unique pour éviter les failles CSRF (Cross-Site Request Forgery)
• Les informations lors de l’ajout de la ligne :
  • La date d’ajout sous la forme d’un DATETIME local ou GMT ou d’un TIMESTAMP
  • Si applicable : une clé étrangère (cf. FOREIGN KEY) liée au compte ou à l’utilisateur qui a ajouté la donnée
  • Si applicable : l’adresse IP de la personne qui ajoute l’information
  • Si applicable : le hostname de cette adresse IP
  • Si applicable : le user agent
  • Si applicable : le détail pour savoir si la ligne a été modifiée à partir de l’interface utilisateur, de l’interface administrateur, d’un CRON ou toute autre interface
• Les mêmes informations lors de la dernière modification de la ligne
• Un commentaire privé destiné à se souvenir des détails concernant cette ligne
• Une information pour savoir si la ligne est active ou si elle a été supprimée, tel que “is_active” ou “is_deleted”. Cela permet de conserver la données tout en la supprimant artificiellement au yeux des utilisateurs en filtrant sur cette valeur

Bien entendu tout ceci est propre à chaque projet et dépend de l’utilisation de chaque table. Il faut savoir que certains projets n’auront nullement besoin de loguer tant d’informations. A titre d’exemple, une application bancaire devra enregistrer un maximum d’information pour sécuriser un maximum l’application, tandis qu’un petit projet peu important n’aura pas l’utilité d’enregistrer le user agent ou le hostname des utilisateurs qui effectuent des modifications.

Cette liste est assez personnelle et peut être enrichie de vos connaissances et bonnes pratiques que vous avez l’occasion de faire dans vos projets utilisant une base de données. Les commentaires sont là pour partager votre expérience.