Dois-je utiliser enum ou interroger une table dans ma base de données?

Question

Dans ma base de données J'ai des tables qui définissent les types par exemple

Tableau: Types de publication

 

ID | Type 
---------- 
1 | Article 
2 | Abstract 
3 | Book 
.... 

Ce qui est lié par la clé d'identification à une table de publication qui a le champ TypeId.

Je crée ensuite une table de données PublicationTable, mon application .NET que je veux filtrer en fonction du type de publication. Par exemple, la fonction suivante me donne le nombre de publications pour un auteur spécifique et un type de publication.

 

    Public Function countPublications(ByVal authorID As Integer, _ 
             ByVal publicationType As Integer) As Integer 

     Dim authPubs As New PublicationsDataSet.tblPublicationsDataTable 
     authPubs = Me.getAuthorsPublications(authorID) 

     Dim dv As New DataView(authPubs) 
     dv.RowFilter = "status='published' AND type='" + _ 
         publicationType.ToString + "'" 

     Return dv.Count 

    End Function 

Pour appeler cette fonction pour obtenir un nombre d'articles par un auteur d'un type particulier, je pouvais

1. appel de la fonction avec deux entiers

   countPublications (AuthorID, 1)

2. configurer un ENUM pour que je puisse écrire

   countPublications (AuthorID, pubType.Article)

   ou

3. utilisent en quelque sorte la table type de publication pour filtrer les données de publication prévue, mais je n'ai pas ma tête sur la façon de le faire.

Quelles autres approches dois-je envisager.

Merci

Answer 1

si les types de publication sont essentiellement statiques, les énumérations sont très bien

il y a une différence sans doute peu entre l'intégration

inner join lookuptable lt on lt.id = (int)myenum.sometype 

dans une requête et en ajoutant

inner join lookuptable lt on lt.name = "somehardcodeddescription" 

ils sont les deux constantes intégrées, le premier a juste un bien-d Type efined derrière

alternativement vous pouvez utiliser

inner join lookuptable lt on lt.name = myenum.sometype.ToString 

je préfère l'ancien

si, d'autre part, de nouveaux types de consultation peuvent être ajoutés après le code est déployé, puis un ENUM rapidement devenir obsolète;

mais s'il y a ensemble de valeurs fondamentales enum statiques que les besoins de code et le reste ne compte pas alors la première solution est toujours très bien

comme d'habitude, « ça dépend » ;-)

Answer 2

Ayant maintenu ce genre de chose dans une vie antérieure, je suis d'accord avec Steven qu'un enum est tout à fait raisonnable. Votre code est clair et un enum signifie que vous devez mettre à jour un seul fichier si vous ajoutez des types de données.

Je suggère également de commenter le enum, en précisant que les valeurs doivent correspondre à celles de la table Publication Types dans votre base de données.

Bonne question, au fait! +1 pour expliquer la question si clairement et prendre le temps de réfléchir à des solutions avant de poster.

Answer 3

Je pense que cela dépend de la fréquence à laquelle votre liste de types de publications changera dans le futur, et de la facilité avec laquelle vous pouvez mettre à jour une mise à jour de votre application. Si la liste ne change pas souvent, ou si la mise à jour de votre application sur le terrain est facile, alors une énumération est logique. Si la liste est susceptible de changer fréquemment, ou si la mise à jour de votre application est particulièrement difficile, il est judicieux de conserver la liste dans une table dans la base de données.

Answer 4

Pour diverses raisons, il serait bon de conserver des listes telles que ma liste de types de publication et d'autres en un seul endroit; la base de données. Ensuite, il n'y a qu'un seul endroit pour eux de changer. Cependant, il me semble que cela ajoute une certaine complexité au code et que je devrais encore avoir des éléments codés en dur dans le code si je voulais me référer à un type de publication spécifique tel que les articles de revues. Par conséquent, ayant un type énuméré qui reflète les données dans le tableau me donne la possibilité d'appeler ma fonction de comptage d'une manière lisible

countPublications(authorID, publicationType.JournalArticle) 

Si les données contenues dans les changements de table qui est peu probable, je peux avoir un commentaire dans la base de données pour rappeler au mainteneur (probablement moi) de mettre à jour le type énuméré dans le code et vice versa.

Merci à tous pour vos réponses. Je peux maintenant procéder avec mon esprit à l'aise.