Conception de valeurs de recherche

Question

Je me demande quel est le protocole de votre magasin de développement ou de votre projet pour traiter les valeurs de recherche, telles que les pays du monde ou les États des États-Unis d'Amérique.

Je l'ai vu de deux manières différentes: à un endroit où je travaillais, nos recherches étaient toutes stockées dans une table de base de données avec le préfixe "L_" et avaient les colonnes suivantes: id, code, desc, ordersequence. Ainsi, par exemple, pour les pays du monde, nous aurions une table comme:

CREATE TABLE L_Countries(

    CountryID INT IDENTITY(1,1) PRIMARY KEY, 

    CountryCode VARCHAR(10) NOT NULL, 

    CountryDesc VARCHAR(50) NOT NULL, 

    OrderSequence INT NULL 

) 

Plus récemment, je l'ai vu un exemple où les recherches sont cuits dans énumérations, par exemple:

enum Countries 
{ 

    Croatia = 1, 

    Slovenia = 2, 

    Serbia = 3, 

    // and so on 

} 

Dans le Si ces événements proviennent d'une table de base de données, il existe un utilitaire qui générera le code C# pour l'énumération. Sinon, quelqu'un prend juste le temps de coder en dur toutes les entrées en supposant que les valeurs sont peu susceptibles de changer. Pour les valeurs numériques de l'énumération, elles sont codées en dur en fonction de la colonne ID dans la table de correspondance correspondante de la base de données, ou simplement codées en dur en fonction de l'entrée commençant par 1.

L'argument de la première approche qui, Certes, je préfère, c'est qu'il est assez flexible donnant la possibilité d'utiliser des codes ou des descriptions complètes, de manipuler l'ordre, et de faire des changements sans avoir à recompiler. Bien que la possibilité de générer du code à partir d'eux est possible, un gros avantage est qu'ils restent de vraies "recherches" lorsqu'ils sont relégués à la base de données. Enfin, la façon dont ils peuvent être utilisés est flexible: en tant que valeurs dans une collection de Dictionary ou en générant des éléments ListLtems ASP.NET ou des éléments de type combobox html avec un code côté serveur. Arguments J'ai entendu dire pour ce dernier que les valeurs ne changeront pas, et qu'il y a un surcoût à devoir récupérer les valeurs de recherche de la base de données même si elles sont mises en cache au niveau de l'application. En les codant en dur ou en générant un Enum, ils sont disponibles sans pénalité de récupération de base de données.

Mes questions sont les suivantes:

1. Quelle option est plus logique de vous ou, si votre réponse est « ça dépend », pouvez-vous donner un scénario dans lequel les énumérations hardcoded sont mieux qu'une base de données recherche à travers une application entière?

2. Y a-t-il d'autres façons de trouver une solution élégante aux problèmes de recherche? J'ai travaillé sur une application où il y avait une seule table pour toutes les recherches (elle incluait une colonne "lookupname") à titre d'exemple. Comment votre approche alternative se compare-t-elle aux deux approches ci-dessus?

Answer 1

Si l'information est très statique et utilisé pour le contrôle des flux, etc. J'utiliser un ENUM (c.-à-nous les utilisons pour les types de formulaires médicaux, les différentes options sur les formulaires médicaux, etc.)

Si l'information est statique mais plus grande, ou si aucune valeur ou expressivité ne serait offerte en en faisant une énumération, et elle n'est pas nécessaire pour les jointures, etc. nous la stockons en XML ou une hashtable et la lisons au besoin et/ou incorporons la ressource. Si l'information va être utilisée dans des jointures de base de données, est trop volumineuse, ou s'il est simplement plus pratique de la stocker dans une table de recherche de base de données, nous le faisons généralement avec un int comme clé primaire.

Espérons que ça aide

Answer 2

Ces approches ne sont pas mutuellement exclusives. J'ai utilisé CodeDom pour générer automatiquement le code enum à partir de la table de base de données. Il y a un problème de bootstrap (c'est-à-dire comment peupler et gérer la base de données elle-même), mais vous pouvez générer l'enum dans une étape de construction, assurant ainsi que les deux ne se désynchronisent jamais.

Answer 3

La norme ISO pour les codes de pays comporte 2 ou 3 caractères. La norme ISO pour les noms de pays est de 40 caractères. L'ISO spécifie également des identifiants numériques pour tous les pays.

Je ne vois aucun intérêt à utiliser IDENTITY comme clé dans cette table car les valeurs doivent apparemment être générées au moment du design pour ENUM et ne pas être insérées au moment de l'exécution. À moins qu'il ne soit utilisé d'une manière ou d'une autre, je vous suggère de supprimer la propriété IDENTITY et de rendre le code de pays unique. À l'heure actuelle, la conception est faible du point de vue de l'intégrité des données, car il lui manque une clé naturelle.