J'ai conçu une table appelée USER_REQUESTS. Il a un champ appelé STATUS, dont le but est de capturer l'état actuel de la demande. Il peut être quelque chose comme soumis, en cours, terminé etc ... Maintenant, mes questions sont, dois-je créer une table maître pour contenir le statut de demande possible? Si oui, quels seraient les avantages?Conception de base de données - Clarification
L'état est un État objet.
objets de l'Etat ont plus qu'un nom (« soumis », « en cours », « terminé »)
La plupart du temps un objet Etat a un ensemble d'états suivants juridiques. Certains Etats (c'est-à-dire "terminés") n'ont pas d'état suivant.
La plupart du temps un objet d'état a un processus qui fera avancer la chose d'un état à l'état suivant. Dans certains cas, vous pouvez nommer ce processus dans le cadre de l'état.
Vous devriez avoir un tableau comme celui-ci.
State Name | Process | Success Next State | Failure Next State
submitted | start "some.sh" | in progress | submitted
in progress| check script | completed | failed
Maintenant, votre application fournit simplement une implémentation pour chaque étape de "processus". Le "workflow" global est défini par votre table d'état.
Vous pouvez facilement reconfigurer votre application en modifiant la définition de vos états.
Voilà l'avantage.
Vous n'avez pas avez à, mais c'est une bonne pratique de le faire - ces tables qui ne contiennent qu'un ensemble de valeurs sont communément appelées tables de consultation.
De cette façon, vous pouvez limiter la STATUT valeurs dans vos USER_REQUESTS table pour correspondre uniquement aux STATUT valeurs possibles.
Certaines bases de données vous permettent de définir un type ENUM qui limitera les valeurs de cette manière.