Bien faire sa base de données

Souvent faire une base de données est une opération simple, la base consiste en un simple tableau qui est rempli. Pas de références croisées, pas de grande table, pas de recherche.

Ainsi une table, ses champs (encore faut-il appliquer le bon type de données à chaque champ) et c’est prêt.

Si on augmente un peu le niveau, des difficultés peuvent surgir en fin de projet lors des tests : résultat trop lent, données manquante ou dur à obtenir, doublon dans les résultats des requètes.

Il faut donc une base de données solide pour tenir la charge du site.

Pour cela, la première étape, bien définir les entités par exemple une commande c’est : des informations globales, des produits, un client (Dans la version simple).  On aura donc :

• Une table « commande » avec un numéro de commande, le numéro du client.
• Une table « produit-commande » avec le numéro du produit, la quantité et le numéro de commande.

Cette structure comporte quelques défauts que voici et la solution qui correspond :

• On ne peut changer le prix d’un produit dans une commande sans le changer sur toutes les commandes.
  Il suffit de rapatrier toutes les infos utiles à la commande dans la table « produit-commande », ainsi la table devient : numeroproduit,quantite,numerocommande,prix
• L’utilisateur change d’adresse entre temps et le colis n’arrive pas au bon endroit ou
  Je change le prix d’un produit entre-temps et le total de la commande ne correspond pas  au chèque reçu
  La solution est assez similaire au point précédent : il faut copier les données qui seront fixe lors de la commande, donc copier les informations clients dans la table de commande.
• Le site est fluide mais la page « Mes commandes » est très longue
  Ce que fait cette page contrairement au reste du site : elle cherche, même si c’est une égalité sur un nombre, elle à deux fonctionnement possible, soit parcourir toutes les lignes et comparer, ce qui marchera au début, soit avoir un index des valeurs et lignes correspondantes ce qui marchera même au delà d’un million de ligne. Sur 150 000 ligne, chercher 1000 fois un email prend 1000 secondes (1 email/seconde) avec un index sur la colonne, la recherche se fait à une vitesse d’environ 500email/seconde.
• Ma base contient les bonnes informations mais la moindre recherche est très longue
  Quel champs sont utile directement et lesquels peuvent êtres mis dans une seconde table ? Pour faire une recherche, il faudra charger en mémoire la table. par conséquent, pour la page de liste des commandes d’un client, est-ce requis d’avoir le message cadeau ? Les points fidélités ? Le code promotion ? Etc etc.
  Pour cette page (et d’autre), les seules informations requises sont : Le numéro de client, le numéro de commande, le prix, le status. Dans ce cas pourquoi charger toutes les autres informations ? Autant mettre les champs de base et de recherche dans une table primaire, et les informations autres dans une seconde table qu’on interrogera au besoin.
• J’ai supprimé un produit, mais les commandes ont un total différent du contenu
  Les listes produits des commandes chargent des informations depuis les produits, si on supprime un produit, les lignes qui correspondent à ce produit ne se chargeront plus sur les anciennes commandes, la solution est de ne pas supprimer (interdire la commande DELETE) mais de rajouter un champ « actif » et de toujours filtrer sur ce champ. Les tailles de stockage actuelle font en sorte qu’un archivage systématique est moins dangereuse qu’une suppression.

Au final on obtient une structure rapide, efficace qui pourra tenir des millions d’enregistrement et ne subira aucun ralentissement peut importe l’opération.