Enums dans la DB ou NO Enums dans la DB

Question

Pour moi, la sagesse classique est de stocker des valeurs enum (OrderStatus, UserTypes, etc) comme tables de recherche dans votre base de données. Cela me permet de renforcer l'intégrité des données dans la base de données, en empêchant les valeurs fausses ou nulles, etc.

Cependant, de plus en plus, cela ressemble à une duplication inutile pour moi. Non seulement dois-je créer des tables pour ces valeurs (ou avoir une table de consultation centrale lourde), mais si je veux ajouter une valeur, je dois me rappeler de l'ajouter à 2 (ou plus, comptant la production, les essais,) et les choses peuvent se désynchroniser facilement.

J'ai encore du mal à relâcher les tables de recherche.

Je sais qu'il y a probablement certains scénarios où l'un a un avantage sur l'autre, mais quelles sont vos pensées générales?

Answer 1

J'ai fait les deux, mais je préfère maintenant les définir comme dans les classes de code.

Les nouveaux fichiers ne coûtent rien, et les avantages que vous recherchez en les intégrant dans la base de données doivent être traités comme des règles métier.

En outre, j'ai une aversion pour la conservation des données dans une base de données qui ne change pas vraiment. Et il semble qu'une énumération corresponde à cette description. Cela n'a pas de sens pour moi d'avoir une table de consultation des États, mais une classe d'énumération des États a du sens pour moi.

Answer 2

Je les mets dans la base de données, mais je ne peux vraiment pas défendre pourquoi je le fais. Cela "semble juste". Je suppose que je le justifie en disant qu'il y a toujours une «bonne» version de ce que les enums peuvent être en vérifiant la base de données.

Answer 3

S'il doit être maintenu, je les laisserais dans une table de recherche dans la base de données. Même si je pense qu'ils n'auront pas besoin d'être entretenus, j'irais toujours vers une table de consultation, de sorte que si je me trompe, ce n'est pas grave.

EDIT:

Je tiens à préciser que si le Enum ne fait pas partie du modèle DB alors je laisse dans le code.

Answer 4

dépendances de schéma doivent être stockés dans la base de données elle-même pour assurer que toutes les modifications apportées à votre architecture peut être facilement effectuer de manière transparente à l'application ..

Answer 5

Je préfère énumérations qu'il applique la liaison anticipée des valeurs dans le code, de sorte que les exceptions ne sont pas causés par des valeurs manquantes

Il est également utile si vous pouvez utiliser la génération de code qui peut amener les associations des colonnes entières à un type d'énumération, de sorte qu'en logique métier, vous ne devez traiter que des valeurs d'énumération facilement mémorisables .

Answer 6

Considérez cela comme une forme de documentation.

Si vous avez déjà documenté correctement les constantes enum dans le code qui utilise le dB, avez-vous vraiment besoin d'un ensemble de documentation en double (à utiliser et à maintenir)?