meilleures pratiques avec des tables de code ou consultation

Question

[UPDATE] approche choisie est ci-dessous, en réponse à cette question

Salut,

J'ai regardé autour de ce sujet, mais je ne peux pas vraiment trouver ce que je cherche ...

Avec les tableaux de code, je veux dire: des choses comme «statut marital», genre, états juridiques ou sociaux spécifiques ... Plus précisément, ces types ont seulement des propriétés et les éléments ne sont pas sur le point de changer bientôt (mais pourrait). Les propriétés étant un identifiant, un nom et une description.

Je me demande comment gérer ces meilleures dans les technologies suivantes: (plusieurs tables, une table avec différentes touches-code ...)

• dans la base de données

• création les classes (probablement quelque chose comme l'héritage d'ICode avec ICode.Name et ICode.Description)

• créer la vue/présentateur pour ceci: il devrait y avoir un écran contenant tous, donc une liste des types (genre, marital statut ...), puis une liste de valeurs pour ce type avec un nom & description pour chaque élément de la liste de valeurs.

Ce sont des choses qui apparaissent dans chaque projet, il doit y avoir une meilleure pratique sur la façon de gérer ces ...

Pour mémoire, je ne suis pas vraiment friands d'utiliser les énumérations pour ces situations ... Tous les arguments sur les utiliser ici sont les bienvenus aussi.

[SUIVI]

Ok, j'ai eu une belle réponse par CodeToGlory et Ahsteele. Affinons cette question. Disons que nous ne parlons pas de genre ou de statut marital, que les valeurs ne changeront certainement pas, mais de "trucs" qui ont un nom et une description, mais rien de plus. Par exemple: statuts sociaux, statuts juridiques.

UI: Je ne veux qu'un seul écran pour cela. Listbox avec possibe NameAndDescription Types (je les appelle juste cela), listbox avec des valeurs possibles pour le type NameAndDescription sélectionné, puis un champ Name et Description pour l'item de type NameAndDescription sélectionné.

Comment cela peut-il être géré dans View & Présentateurs? Je trouve la difficulté ici que les types NameAndDescription auraient alors besoin d'être extraits du nom de la classe?

DB: Quels sont les avantages et les inconvénients des tables de recherche multiples par rapport aux tables de recherche uniques?

Answer 1

J'ai décidé d'aller avec cette approche:

CodeKeyManager mgr = new CodeKeyManager(); 
CodeKey maritalStatuses = mgr.ReadByCodeName(Code.MaritalStatus); 

Où:

• CodeKeyManager peut récupérer CodeKeys de DB (clé de code = MaritalStatus)
• code est une classe remplie de constantes, renvoyer des chaînes de sorte que Code.MaritalStatus = "maritalStatus".Ces constantes carte à la table clé de code> CodeKeyName
• Dans la base de données, j'ai 2 tables:
  • clé de code avec Id, CodeKeyName
  • CodeValue avec CodeKeyId, ValueName, ValeurDescription

DB:

alt text http://lh3.ggpht.com/_cNmigBr3EkA/SeZnmHcgHZI/AAAAAAAAAFU/2OTzmtMNqFw/codetables_1.JPG

Code Classe:

public class Code 
{ 
    public const string Gender = "gender"; 
    public const string MaritalStatus = "maritalStatus"; 
} 

Classe clé de code:

public class CodeKey 
{ 
    public Guid Id { get; set; } 
    public string CodeName { get; set; } 

    public IList<CodeValue> CodeValues { get; set; } 
} 

Classe CodeValue:

public class CodeValue 
{ 
    public Guid Id { get; set; } 

    public CodeKey Code { get; set; } 

    public string Name { get; set; } 
    public string Description { get; set; } 

} 

Je trouve de loin le moyen le plus simple et le plus efficent:

• Tous les données de code peuvent être affichées dans un identifiant manière entical (dans la même vue/présentateur)
• Je ne ai pas besoin de créer des tables et des classes pour toutes les tables de code qui est à venir
• Mais je peux toujours les faire sortir de la base de données facilement et de les utiliser facilement avec la constantes ...
clé de code
• NHibernate peut gérer cela facilement trop

la seule chose que je considère encore est de jeter le GUID Id et en utilisant les codes (chaîne nchar) pour la facilité d'utilisation dans la logique métier.

Merci pour les réponses! S'il y a des remarques sur cette approche, faites s'il vous plaît!

Answer 2

Couple de choses ici:

1. Utilisez énumérations qui sont explicitement claires et ne changeront pas. Par exemple, MaritalStatus, Gender etc.

2. Utilisez les tables de recherche pour les éléments qui ne sont pas corrigés comme ci-dessus et qui peuvent changer, augmenter/diminuer avec le temps.

Il est très courant d'avoir des tables de recherche dans la base de données. Définissez un objet clé/valeur dans votre niveau métier qui peut fonctionner avec votre vue/présentation.

Answer 3

Je préfère utiliser une représentation de table pour ce type de données. En fin de compte, si vous avez besoin de capturer les données, vous aurez besoin de les stocker. À des fins de rapport, il est préférable d'avoir un endroit où vous pouvez tirer ces données à partir d'une clé. À des fins de normalisation, je trouve que les tables de recherche à usage unique sont plus faciles à utiliser qu'une table de consultation à usages multiples.

Cela dit énumérations fonctionner assez bien pour des choses qui ne changeront pas comme le sexe, etc.

Answer 4

En utilisant la base de données axée sur les tables de code peut très utile. Vous pouvez définir la durée de vie des données (en utilisant les dates de début et de fin), ajouter des données à la table en temps réel pour ne pas avoir à déployer de code et autoriser les utilisateurs (avec les bons droits bien sûr) ajouter des données via des écrans d'administration.

Je recommande toujours d'utiliser une clé primaire autonumber plutôt que le code ou la description. Cela vous permet d'utiliser plusieurs codes (du même nom mais avec des descriptions différentes) sur différentes périodes. Plus la plupart des DBA (dans mon expérience) utilisent plutôt le numéro automatique sur les clés primaires basées sur le texte.

Je voudrais utiliser une seule table par liste codée. Vous pouvez mettre tous les codes dans une table qui ne se rapporte pas (en utilisant une sorte de matrice), mais cela devient salissant et je n'ai trouvé que quelques situations où c'était utile.

Answer 5

Pourquoi tout le monde veut compliquer les tables de codes? Oui, il y en a beaucoup, mais ils sont simples, alors gardez-les comme ça. Traitez-les simplement comme jamais un autre objet. Ils font partie du domaine, alors modélisez-les comme faisant partie du domaine, rien de spécial. Si vous ne le faites pas quand ils ont inévitablement besoin de plus d'attributs ou de fonctionnalités, vous devrez annuler tout votre code qui l'utilise actuellement et le retravailler.

Un tableau par cours (pour l'intégrité référentielle et de sorte qu'ils soient disponibles pour la création de rapports).

Pour les classes, encore une par bien sûr car si j'écris une méthode pour recevoir un objet "Genre", je ne veux pas pouvoir passer accidentellement un "MarritalStatus"! Laissez la compilation vous aider à éliminer les erreurs d'exécution, c'est pourquoi c'est là. Chaque classe peut simplement hériter ou contenir une classe CodeTable ou autre chose, mais c'est simplement une aide à l'implémentation.

Pour l'interface utilisateur, si elle utilise effectivement le CodeTable hérité, je suppose que vous pourriez l'utiliser pour vous aider et simplement le maintenir dans une interface utilisateur. En règle générale, ne pas gâcher le modèle de base de données, ne pas gâcher le modèle d'affaires, mais vous ne voulez pas tourner un peu dans le modèle de l'interface utilisateur, ce n'est pas si mal.