Type à utiliser pour les colonnes "Status" dans une table sql
j'ai un (dummy) structure de la table comme suit:
ticket id: int(11) PK name: varchar(255) status: ?????????
la question Est, quel type de données dois-je utiliser pour le statut? Voici mes options, tels que je les vois:
- varchar représentant le statut-BAD parce qu'il n'y a pas d'intégrité
- enum représentant l'état - MAUVAIS parce que pour modifier la valeur, je dois modifier la table, et puis n'importe quel code avec des listes déroulantes pour les valeurs, etc etc etc
- int FK à un tableau d'état - BONNE cause c'est dynamique, mauvais parce que c'est plus difficile à inspecter à vue (ce qui peut être utile)
- varchar FK à une table d'état-bon parce que c'est dynamique, et visible à l'inspection. Mauvais parce que les clés sont significatives, ce qui est généralement mal vu. Fait intéressant, dans ce cas, il est tout à fait possible que la table de statut n'ait qu'une colonne, ce qui en fait un énum glorifié
ai-je une idée précise de la situation? Est d'avoir un véritable touche vraiment si mauvais? Parce bien que ça me donne la chair de poule, je n'ai aucune raison de le faire...
mise à Jour: Pour l'option 4, la structure proposée serait statut: char (4) FK pour un tableau d'état. Donc,
OUVRIR => "Ouvrir"
CLOS = > "Closed"
"PEND" => "en Attente d'Autorisation"
"PROG" = > " en cours
Quel est l'inconvénient dans ce cas ? Le seul avantage que je peux voir de l'utilisation int sur char dans ce cas est une performance légère.
6 réponses
Aller avec le numéro 3. Créez une vue qui join's dans la valeur status si vous voulez quelque chose inspectable.
je voudrais aller avec le numéro 4, mais je préfère utiliser un char(x) colonne. Si vous êtes inquiet au sujet de la performance, un char(4) prend autant d'espace (et, du moins on pourrait penser, l'e/s du disque, la bande passante, et le temps de traitement) qu'un int, qui prend aussi 4 octets à stocker. Si vous êtes vraiment inquiet au sujet de la performance, faites-en un char(2) ou même un char(1).
ne le voyez pas comme une" donnée significative", mais comme une abréviation de la clé naturelle. Oui, les données ont un sens, mais comme vous l'avez remarqué, être une bonne chose en travaillant avec les données--cela signifie que vous ne devez pas toujours joindre (même si à une petite table triviale) pour extraire le sens de la base de données. Et bien sûr, la contrainte de clé étrangère garantit que les données sont valides, puisqu'elles doivent être dans la table de recherche. (Cela peut aussi être fait avec des contraintes de vérification, mais les tables de recherche sont généralement plus faciles à gérer et à maintenir au fil du temps.)
L'inconvénient est que vous pouvez être pris à essayer de trouver un sens. char (1) a un forte d'appel, mais si vous arrivez à dix ou plus de valeurs, il peut être difficile de venir avec bonne des valeurs significatives. Moins d'un problème avec char(4), mais encore un problème possible. Un autre inconvénient: si les données sont susceptibles de changer, alors oui, vos données significatives ("PEND" = "en attente D'autorisation") peuvent perdre leur signification ("PEND" = "envoyer au bureau à domicile pour approbation initiale"). C'est un mauvais exemple; si des codes comme celui-là changent, vous êtes probablement beaucoup mieux de reconfigurer votre système pour tenir compte du changement apporté aux règles administratives. Je pense que mon point devrait être, si c'est une valeur de recherche entrée par l'utilisateur, les clés de substitution (entiers) seront votre ami, mais si elles sont définies et maintenues en interne, vous devriez certainement envisager des valeurs plus conviviales pour les humains. Cela, ou vous aurez besoin de post-em notes sur votre moniteur pour vous rappeler ce que le statut heck = 31 est censé signifier. (J'ai trois sur le mien, et le stickum porte tous les quelques mois. Parler de coût d'entretien...)
j'utiliserais un INT, et créerais une relation clé étrangère à la table de statut. Un INT devrait être sûr pour une colonne de statut énuméré.
puis-je vous recommander d'utiliser un champ statusID à la place, et d'avoir une table séparée cartographiant L'ID à un varchar?
EDIT: je suppose que c'est exactement ce que vous avez décrites au point 3. Je pense que c'est la meilleure option.
je suppose que votre base de données a un début de description, et que les utilisateurs réguliers ne sont pas exposés au code de statut.
ainsi, votre convenance est seulement pour les programmeurs et les personnes importantes DBAs, mais je ne voudrais pas optimiser mon design pour eux.
plus fort - je serais très prudent d'utiliser des abréviations "significatives" - le plus grand gâchis de données que j'ai jamais vu s'est produit quand un développeur nettoyait certaines données, et a interprété la clé "significative" incorrectement; il s'avère que "PROG" ne signifie pas "programmé", mais"en cours".
choisir l'option 3.
créer une table séparée avec le statut est une bonne idée quand vous voulez montrer la liste du statut dans le formulaire HTML. Vous pouvez afficher la description verbeuse à partir de la table de recherche et cela aidera l'utilisateur à choisir le statut si les exigences sont comme cela.
du point de vue du développement, je voudrais aller entier comme une clé primaire. Vous pouvez l'optimiser en utilisant de petit/minuscule entier si vous savez qu'il ne dépasse pas la limite.
si vous utilisez une abréviation foreign key alors vous devez penser à chaque fois pour le rendre unique tout le temps comme @Philip Kelley l'avait mentionné comme un inconvénient de celui-ci.
enfin, vous pouvez déclarer le type de table MYISAM si vous le souhaitez.
mise à jour: Pour refléter l'opinion de @Philip Kelley, s'il y a trop de statut, alors il est préférable d'utiliser entier comme clé étrangère. S'il y a seulement quelques statuts, alors peut être utiliser abbr comme une clé étrangère.