Pour moi, la sagesse classique consiste à stocker des valeurs ENUM (orderstatus, ustyps, etc.) en tant que tables de recherche de votre DB. Cela me permet d'appliquer l'intégrité des données dans la base de données, de prévenir les valeurs fausses ou nuls, etc.
Cependant, de plus en plus, cela ressemble à des doubles emplois inutiles. Non seulement je dois créer des tables pour ces valeurs (ou avoir une table de recherche centrale sans terrain), mais si je veux ajouter une valeur, je dois m'empêcher de l'ajouter à 2 (ou plus, de compter la production, des tests, des dB en direct. ) et les choses peuvent sortir facilement de synchronisation.
toujours j'ai du mal à abandonner les tables de recherche.
Je sais qu'il y a probablement certains scénarios où l'on avait un avantage sur l'autre, mais quelles sont vos pensées générales?
6 Réponses :
Je les ai mis dans la base de données, mais je ne peux vraiment pas défendre pourquoi je fais cela. Il "semble juste". Je suppose que je le justifie en disant qu'il y a toujours une version "droite" de ce que les Enums peuvent être en vérifiant la base de données.
Si cela doit être maintenu, je les laisserais dans une table de recherche dans la DB. Même si je pense qu'ils n'auront pas besoin d'être maintenus, je vais toujours vers une table de recherche afin que si je me trompe, ce n'est pas une grosse affaire.
EDIT:
Je veux clarifier que si l'énumé ne fait pas partie du modèle de base de données, je le laisse en code.
Qu'est-ce qui ne serait pas considéré comme faisant partie du modèle de DB?
Tout ce qui n'est pas stocké dans la base de données dans le cadre d'une entrée d'enregistrement dans une table.
J'ai fait les deux, mais je préfère maintenant que je les défini comme dans des classes dans le code.
Les nouveaux fichiers ne coûtent rien et les avantages que vous recherchez en l'aviez-vous dans la base de données, devraient être traités comme des règles commerciales.
En outre, j'ai une aversion pour détenir des données dans une base de données qui ne change vraiment pas. Et il semble qu'un énum convient à cette description. Il n'a pas de sens que moi d'avoir une table d'ascendance des États, mais une classe Etats-Unis a du sens pour moi.
Comment vous gérez-vous de vous assurer que aucune ligne n'a de valeur non valide pour leur énorme? Il suffit d'utiliser le code qui accède à la DB?
Les dépendances de schéma doivent être stockées dans la base de données elle-même pour que toute modification de votre architecture puisse être facilement effectuée de manière transparente à l'application ..
Je préfère les énumes, car il applique une liaison anticipée de valeurs dans le code, de sorte que les exceptions ne soient pas causées par des valeurs manquantes
Il est également utile que vous puissiez utiliser la génération de code pouvant amener les associations des colonnes entier à un type d'énumération, de sorte que dans la logique commerciale que vous devez uniquement faire face à des valeurs de dénombrement facilement mémorables.
Considérez-le une forme de documentation.
Si vous avez déjà documenté correctement les constantes ENUM dans le code qui utilise la base de données, avez-vous vraiment besoin d'un ensemble de documentation en double (pour utiliser et entretenir)?
En y pensant d'autres, je suppose que cela revient à y réfléchir comme une application basée sur la base de données ou une application utilisant une base de données pour stocker son état. Ce que je veux dire, c'est penser à la base de données en tant qu'entité indépendante, qui peut être utilisée par d'autres applications ou services, auquel cas l'intégrité des données est essentielle. Versus avoir la DB comme un simple magasin de données pour l'application, s'appuyant sur l'application pour appliquer les règles d'intégrité des données. Dans ce cas, les relations ne sont probablement pas nécessaires.