Voici quelques bonnes pratiques à utiliser dans les bases de données :

• Dans une base de données, il est préférable d'écrire le nom de l'identificateur correspondant à l'autre table plutôt que de simplement écrire «id». Les raisons sont multiples :
• Évité les confusions de clef étrangères lors de la conception avec des logiciels comme «VISIO». Ces genres de logiciel créeront souvent un champs automatiquement parce que le nom des deux clefs ne sont pas identiques.
• Permet d'effectuer un copier-coller lors d'écriture de requête SQL avec des «LEFT JOIN» par exemple.
• On peut retrouvé ou remplacé beaucoup plus facilement dans un langage de programmation évolue les identificateurs s'en avoir l'obligation de les vérifiés une par une.
• Il est préférable de toujours mettre les noms de tables en minuscules, en particulier dans la base de données MySQL, car lorsqu'on tente d'exécuter les mêmes requêtes Windows sous Linux, elles ne fonctionnent plus à cause que le nom du fichier est introuvable! Donc on évite bien des ennuis en mettant tous les noms de table en minuscules!
• Il est préférable de conserver une copie de la structure des tables de base de données dans un format SQL. Ainsi, ils sont facilement récupérables en cas de corruption de données ou de changement de base de données.
• Avec des bases de données efficaces, comme Oracle par exemple, il est préférable de regrouper plusieurs requêtes en une seule pour éviter le rappel constant à un service. Le délai pour un appel d'un service distant est toujours très long par rapport à un traitement en interne.
• Ne pas hésiter a rajouter des index correspondants au critère de recherche «WHERE» ou à de tris «ORDER BY».
• Utiliser un «AUTO_INCREMENT» plutôt que d'utiliser un «SELECT MAX(ID) FROM table». La raison c'est qu'il y a moins de risques d'avoir un conflit lorsque deux utilisateurs distincts insèrent des données dans une même table. Ensuite, on peut retrouvé l'identificateur avec «LAST_INSERT_ID», si on l'effectue dans la même transaction.
• Une table devrait toujours avoir une clef primaire, une clef secondaire ou un identificateur unique.
• Ne jamais conserver en claire un mot de passe, un numéro de carte de crédit, d'Assurance Sociale ou n'importe quelle information d'identification sensible, utiliser des encodages du genre MD5, SHA-1, SHA256,...

Exemples

Certains développeurs ont tendance à mettre vraiment n'importe quoi dans la base de données. Exemple d'une mauvaise pratique que j'ai vue dans un CMS commercial. Un développeur mettant un connecteur (IP, utilisateur et mot de passe) vers 3 autres bases de données dans une table de la base de données avec les mots de passe en claire. Ce genre de pratique, est carrément une faille de sécurité dans une application ! Ainsi, un administrateur réseau ne sera pas en mesure de protéger l'information d'un utilisateur ayant un accès réduit SSH.

La conscience de la performance et du trafic élevé dans une application n'est pas toujours bien perçue par les développeurs. Ainsi, si vous devez uniquement sortie une liste rapide de contenu, certaines applications auront par exemple la mauvaise habitude de toujours faire un «SELECT» étoile plutôt qu'un «SELECT» avec les noms de champs. En apparence anodin, ce petit détail fera en sorte qu'une application lit un enregistrement contenant une description de 30 Ko, alors qu'il n'avait besoin de connaitre que le titre. Sur une table avec des milliers d'enregistrements, vous aurez donc retourné inutilement 500 Ko de données alors que vous n'en aviez besoin que de 10 Ko. Imaginé alors, la surprise des utilisateurs, et du délai d'attente énorme qu'ils subissent lorsqu'ils y a 100 en même temps dessus, vous aurez transmis 50 Mo plutôt que 1 Mo de données !