SQL Server équivalent au type de données enum MySQL?

132

SQL Server 2008 a-t-il un type de données comme celui de MySQL enum?

— Patrick
source

155

Ce n'est pas le cas. Il y a un vague équivalent:

mycol VARCHAR(10) NOT NULL CHECK (mycol IN('Useful', 'Useless', 'Unknown'))

— le chaos
source

10

Pourquoi ne pas utiliser une table qui définit des valeurs valides, puis utiliser une contrainte de clé étrangère à la place?

— Elaskanator

@Elaskanator Je dirais que cela répond le plus précisément à l'OP direct, tandis que la meilleure solution pour cela est probablement l'utilisation de la table externe FK +.

— userfuser

Merci @Elaskanator de m'avoir rappelé l'évidence ... normaliser les données et les énumérations cessent d'exister.

— Andrew

88

La meilleure solution que j'ai trouvée à cet égard est de créer une table de recherche avec les valeurs possibles en tant que clé primaire et de créer une clé étrangère pour la table de recherche.

— user1431422
source

13

Une meilleure solution du point de vue de la maintenabilité que la contrainte de vérification illustrée ci-dessus.

— HLGEM

21

C'est une meilleure solution que Enums - également dans MySQL.

— ypercubeᵀᴹ

2

@ypercube Pourquoi est-ce aussi meilleur pour MySQL?

— BenR

4

@BenRecord Il y a plusieurs problèmes avec les énumérations de MySQL: 8 raisons pour lesquelles le type de données ENUM de MySQL est mauvais . Je ne suis pas d'accord à 100% pour dire que c'est mal mais vous devez être très prudent lorsque vous les utilisez.

— ypercubeᵀᴹ

1

@BenR aussi si je me souviens bien, en mode non strict avec MySQL, une énumération invalide peut être insérée comme NULL. Quelle que soit la condition, une équipe précédente a eu des problèmes avec une énumération MySQL qui n'était pas insérée et n'échouait pas lorsque la valeur n'était pas spécifiée dans la liste de valeurs. Une contrainte de clé étrangère sur une table de recherche entraînerait un échec. Je suis d'accord que la table de recherche est meilleure pour MySQL.

— Jim Schubert

4

Les tables de recherche IMHO sont la voie à suivre, avec l'intégrité référentielle. Mais seulement si vous évitez "Evil Magic Numbers" en suivant un exemple tel que celui-ci: Générer une énumération à partir d'une table de recherche de base de données en utilisant T4

S'amuser!

— Jony Adamit
source

2

CREATE FUNCTION ActionState_Preassigned()
RETURNS tinyint
AS
BEGIN
    RETURN 0
END

GO

CREATE FUNCTION ActionState_Unassigned()
RETURNS tinyint
AS
BEGIN
    RETURN 1
END

-- etc...

Là où la performance compte, utilisez toujours les valeurs strictes.

— Dimitrios Staikos
source

1

J'ai trouvé cette approche intéressante lorsque je voulais implémenter des énumérations dans SQL Server.

L'approche mentionnée ci-dessous dans le lien est assez convaincante, étant donné que tous vos besoins d'énumération de base de données pourraient être satisfaits avec 2 tables centrales.

http://blog.sqlauthority.com/2010/03/22/sql-server-enumerations-in-relational-database-best-practice/

— user_v
source

8

Il s'agit d'une variante de l'anti-modèle connue sous le nom de "une vraie table (de recherche)". L'approche appropriée est d'avoir une table séparée pour chaque type d'énumération et d'utiliser des clés étrangères (si vous avez besoin d'une recherche, ce qui peut ne pas être le cas pour les énumérations "pures").

— Branko Dimitrijevic

2

Les commentaires sur la page liée fournissent une bonne sauvegarde pour utiliser des tables individuelles pour chaque "enum", plutôt que ce que cette réponse spécifie

— skia.heliou

4

C'est assez drôle comment la plupart des gens rechigneraient à juste titre à cette conception, pourtant l'auteur nomme son article «meilleure pratique».

— underscore_d