TSQL et Enum
Sujet apparemment courant, je cherche une idée pour contourner.
J'utilise une enum Etat dans mon code C#.
Je stocke cet état dans ma base (int), et je m'en sert beaucoup dans mes stor proc
(pourquoi ? En gros, la même base est attaquée depuis 3 appli différentes, et suivant l'état un objet est accessible ou pas à telle appli, le tri est fait au niveau base pour alléger la masse de données échangées avec la base)
Seulement voilà, les specs changent tout le temps, et je dois rajouter des états régulièrement, et du coup repasser derrière mes 200 stor procs pour modifier les états, et comme bien entendu c'est à faire pour hier et qu'on n'a pas le temps de tester à 100%, y'a des bugs à la con.
Les solutions déjà pensée :
* Utiliser une chaine : non, ça change trop la volumétrie et c'est plus lent à traiter que des entiers
* Utiliser des nombres spéciaux pour les repérer plus facilement dans les procs en faisant "rechercher tout" (ex : 654343, 654344, ...) => Oui mais c'est de la bidouille
* Utiliser des constantes ? Malheureusement ça n'existe pas en T-SQL
* Créer une table contenant la liste des différents état : c'est plus souple, mais dans les stor procs ça oblige à faire un appel à une fonction ou à faire un select en plus, bref ça ralenti certaines opérations qui ont besoin d'être très optimisées...
Bref : la question est là : comment gérer facilement un mapping avec une enum en T-SQL, sachant que la problématique principale c'est qu'on a des migrations assez régulièrement (agile programming et contraintes métier obligent)
Quelques sources qui parlent du pb mais qui ne donnent pas de solution qui me convienne :
Répondre avec citation
Partager