Type d'un attribut

Bonjour,

Je suis entrain de mettre en place une base de données sous Sql Server, j'ai un attribut performance qui peut prendre soit A soit B soit C, je ne sais pas quel type je dois donner à cet attribut (je n'ai pas trouvé enum), je peux lui donner char(1) mais je ne pourrai pas controller les valeurs de cet attribut.

Et merci d'avance.

Bonjour,

En effet, vous pouvez créer un table du style :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

CREATE TABLE performance_level ( performance_level_id tinyint identity NOT NULL CONSTRAINT PKperformance_level PRIMARY KEY , performance_level_label char(1) NOT NULL , performance_level_description varchar(128) )   INSERT INTO dbo.performance_level (performance_level_label, performance_level_description) VALUES ('A', 'Niveau A') , ('B', 'Niveau B') , ('C', 'Niveau C')

---

Puis référencer cette table par intégrité référentielle (clé étrangère) dans d'autres tables de votre base de données ;)

@++ ;)

Vous auriez aussi pu ajouter une contrainte dans la définition de votre colonne limitant les valeurs à 'A','B' ou 'C'

Effectivement cette 2eme solution est également valable.

Si on supose que les valeurs peuvent changer ou évoluer, la solution donnée par Elsuket est alors plus facile à gérer par la suite. (ajout, modification ou suppression de la liste des valeurs à respecter dans une table avec contrainte de type clé étrangère).

++

Merci pour les réponses,

je pense que meme la solution d'ajout d'une contrainte est facile à gérer par la suite; il suffit d'ajouter les valeurs qu'on veut accepter après.

Tout dépend encore une fois de votre situation :-)

Imaginez que vous ayez à modifier vos valeurs souvent et que vous vouliez le faire depuis votre application ...

Il est plus simple dans ce cas d'avoir un formulaire de saisie qui vous permettra d'entrer, modifier ou supprimer vos valeurs dans la table de référence. Avec une contrainte de type CHECK, le processus de mise à jour depuis l'application sera plus compliqué.

Cependant vous n'êtes peut être pas dans ce cas et auquel cas la solution proposée par iberserk est tout à fait adaptée à votre besoin.

++

Oui, je proposais une autre solution d'un point de vue technique mais personnelement j'utiliserais une table de référence de vos code performances (solution Elsuket).

Ainsi vous donnez plus de lisibilité à votre base de données:
Si un concurrent accordant plus de valeur à vos compétences décident de vous débaucher moyennant une substancielle augmentation et des Tickets resto de 8 euros au lieu de 7,5 :mouarf:, votre successeur sera obligé de fouiller dans le code de votre appli client pour trouver la signification métier de ces codes...