Modélisation des données - comment gérer deux colonnes "status" dépendantes?

Question

J'ai croisé quelque chose qui m'énerve juste assez que je voulais venir ici et chercher une sorte de "meilleure pratique" type de conseils de vous les gars (et gals)

J'ai une table dans mon modèle , appelons-le prospect. Deux systèmes externes distincts peuvent fournir une mise à jour pour les lignes de cette table, mais seulement en tant que "statut" de cet enregistrement dans ces systèmes respectifs.

J'ai besoin de stocker ces statuts localement. Idée initiale, bien sûr, juste pour faire deux clés étrangères nulles. Quelque chose comme ça.

+-----------------+--------------+------+-----+---------+----------------+ 
| Field   | Type   | Null | Key | Default | Extra   | 
+-----------------+--------------+------+-----+---------+----------------+ 
| prospect_id  | int(11)  | NO | PRI | NULL | auto_increment | 
| ext_status_1_id | int(11)  | YES |  | NULL |    | 
| ext_status_2_id | int(11)  | YES |  | NULL |    | 
+-----------------+--------------+------+-----+---------+----------------+ 

Dans cet exemple, il y aurait, bien sûr, deux tables qui contiennent des paires id/valeur pour les états.

est ici les prises - ext_status_2_id sera toujours être NULL sauf si ext_status_1_id est 1 (ce qui est tout simplement la façon dont les règles métier travail).

Ai-je modélisé cela correctement? J'ai juste cette voix lancinante à l'arrière de mon cerveau qui me dit que "toutes les rangées en perspective n'auront pas besoin d'un ext_status_2_id donc cela pourrait ne pas être correct".

S'il importe, c'est MySQL 5.0.45 et j'utilise InnoDB

Answer 1

Comme il y a une dépendance construite pour Status2 sur Status1, pourquoi ne pas avoir juste un champ d'état unique sur la table de perspective, et créer Status2 en tant que propriété sur la table Status1? Il est certainement fortement normalisé de cette façon, mais avoir la structure de données de cette façon parle de la dépendance de Status2 sur Status1.

Answer 2

Ceci est probablement correct. Mais puisque vous n'utiliserez toujours que l'un des 2, vous pouvez le modéliser comme suit:

ext_status_type (1 ou 2) et ext_status pour l'ID réel.

Je ferais probablement la même chose que vous, car il pourrait être plus facile de construire des index autour de cela et les deux nombres semblent avoir une signification différente.

S'il y aura plus de statuts (3,4,5,6) je considérerais la première approche dans ma réponse.

Answer 3

Quels sont les possibles ext__status__1? Est-ce que ext__status__2 aura une valeur seulement si status__1=1? Qu'est-ce que status__1=2? Je suis partiellement d'accord avec Nissan Fan. Y at-il, cependant, une dépendance directe entre status__1 et Status__2? Existe-t-il une dépendance fonctionnelle du formulaire status__1 -> Status__2?
S'il n'y a pas de dépendance, le fait de conserver status__1 et Status__2 dans un tableau séparé ne résout pas le problème.