Clés techniques et clés d’état


19 09 2006

update: remarques en fin d’article

Je suis partisan d’une simplification des tables avec une clé primaire non métier. Ce que l’on nomme généralement clé primaire technique sous forme d’un entier auto-incrementé, c’est mon coté rails qui parle là.

Mais concernant la définition des états je desteste me retrouver avec des entiers de 1 à X décrivant chacun une étape. Exemple :

1 -> Initialisation 2 -> En cours 3 -> Fin traitement OK 4 -> Fin traitement KO 5 -> Stockage 6 -> Sortie

Le gros problème de ce genre d’états est qu’il difficile pour l’esprit humain de garder la correspondance en tête. Surtout quand on se retrouve avec une dizaine de listes différentes comme ceci.

Si l’on prend des données lambda en base utilisant le système précédent, voici ce que l’on pourrait voir dans la base de données :

|   DONNEE  |   ETAT  | |===========|=========| |  entree1  |    1    | |  entree2  |    3    | |  entree3  |    5    | |  entree4  |    2    |

Résultat, on passe son temps à se demander quelle est déjà l’étape correspondante. J’aimerais avoir une façon plus lisible de comprendre ces éléments sans devoir me référer à une autre table ou retrouver dans mon code les différentes implémentations.

Par exemple je trouve ceci plus lisible :

|   DONNEE  |   ETAT  | |===========|=========| |  entree1  |  INIT   | |  entree2  |  T OK   | |  entree3  |  T KO   | |  entree4  |  ENCO   |

Mais j’ai bien conscience que d’une part ce n’est peut-être pas vraiment optimisé car on passe d’une colonne d’entiers à une colonne de caractères (Problème d’index et compagnie) et d’autre part, ca fait un peu charabia cet état sur 4 caractères.

D’autres propositions ?

update: Suite aux commentaires éclairés de Yann (Pas de blog à linker…bientôt ?), je crois que ma refléxion part d’un postulat incorrect. En effet, je base ma réflexion sur un existant où l’on retrouve dans une table des états de 1 à 6. Ces états ne sont pas des clés étrangères pointant vers une table de référence des états et je crois que mon erreur vient de là. Je cherche à résoudre un problème qui n’est pas, et sa résolution est seulement l’affaire d’un travail d’amélioration de la base de données existante.


Billets similaires

Actions

Informations

3 réponses à “Clés techniques et clés d’état”

19 09 2006
Yann (16:48:25) :

Salut,

pourquoi pas une table Etats(id,libelle) et ta table initiale Donnees(libelle,idEtat), idEtat étant une clé etrangère référençant un enregistrement de la table Etats?

19 09 2006
Julien (16:53:18) :

Yann: C’est justement la situation initiale et qui fait qu’on voit des idEtat partout et qu’on ne sait plus à quoi correspond cet id.

Peut-être qu’il n’existe pas de solution à ce problème et que cette solution reste la plus propre…

19 09 2006
Yann (17:03:13) :

Je ne pense pas qu’une bonne conception de tables (avec clé étrangère) soit destinée à une bonne lisibilité.
Pour rendre la lecture plus agréable, on utilise à ce moment là une jointure dans la requête.
Tu cherches une solution, mais y a-t-il vraiment un problème?