les meilleures pratiques avec des tables de code ou consultation

StackOverflow https://stackoverflow.com/questions/753460

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 tables de code, je veux dire: des choses comme « statut maritial », le sexe, les États juridiques ou sociaux spécifiques ... Plus précisément, ces types ont des propriétés que définies et les éléments ne sont pas sur le point de changer rapidement (mais je ne pouvais). Propriétés étant un identifiant, un nom et une description.

Je me demande comment gérer ces meilleures dans les technologies suivantes:

  • dans la base de données (tables multiples, une table avec différentes touches de code ...?)

  • créer les classes (probablement quelque chose comme héritant ICode avec ICode.Name et ICode.Description)

  • création de la vue / présentateur pour cela: il devrait y avoir un écran contenant tous, donc une liste des types (le sexe, le statut maritial ...), puis une liste de valeurs pour ce type avec un nom et une description pour chaque élément de la valeur liste.

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 énumérations pour ces situations ... Tous les arguments sur les utiliser ici sont aussi les bienvenus.

[SUIVI]

Ok, j'ai eu une belle réponse par CodeToGlory et Ahsteele. Nous allons Détailler cette question.

Disons que nous ne parlons pas de sexe ou maritial, les valeurs Wich changeront certainement pas, mais de « trucs » qui ont un nom et une description, mais rien de plus. Par exemple:. Statuts sociaux, statuts juridiques

interface utilisateur: Je veux seulement un écran pour cela. Listbox avec les types possibe de NameAndDescription (je vais les appeler), avec des valeurs listbox possibles pour le type NameAndDescription sélectionné, puis un champ de nom et la description du type de NameAndDescription élément sélectionné.

Comment cela pourrait-il être traité dans la vue et présentateurs? Je trouve la difficulté ici que les types de NameAndDescription devront ensuite être extrait du nom de la classe?

DB: Quels sont pro / contre pour plusieurs vs tables de consultation unique?

Était-ce utile?

La solution 3

Je l'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 (= MaritalStatus clé de code)
  • Code est une classe remplie de constantes, les chaînes retour si Code.MaritalStatus = « maritalStatus ». Ces constantes carte à la table clé de code> CodeKeyName
  • Dans la base de données, j'ai 2 tables:
    • Id avec clé de code, CodeKeyName
    • CodeValue avec CodeKeyId, ValueName, ValeurDescription

DB:

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

Code de 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 codes-données peuvent être affichées de manière identique (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 ne peux toujours les faire sortir de la base de données facilement et de les utiliser facilement avec les constantes de ... clé de code
  • NHibernate peut gérer cela facilement aussi

La seule chose que je considère encore est jeter chaîne et à l'aide de l'GUID Id codes (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, s'il vous plaît faire!

Autres conseils

Base de données des tables de code entrainée peuvent très utile. Vous pouvez faire des choses comme définir la durée de vie des données (en utilisant dates de début et de fin), ajouter des données à la table en temps réel de sorte que vous ne devez pas déployer du code, et vous pouvez permettre aux utilisateurs (avec les bons privilèges bien sûr) ajouter des données à travers des écrans d'administration.

Je recommande de toujours utiliser une clé primaire autonumber plutôt que le code ou la description. Cela permet pour vous d'utiliser plusieurs codes (du même nom, mais différentes descriptions) sur différentes périodes de temps. De plus la plupart des CBM (dans mon expérience) utilisent plutôt la numérotation automatique des clés primaires à base de texte.

J'utiliser une seule table par liste codée. Vous pouvez mettre plusieurs codes tout en une seule table qui ne se rapportent pas (en utilisant une matrice de toutes sortes) mais devient malpropre et je n'ai trouvé une situation couple où il était même utile.

Couple de choses ici:

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

  2. Utilisez des tables de consultation pour les articles qui ne sont pas fixés comme ci-dessus et peuvent changer, augmentation / diminution au fil du temps.

Il est très typique des tables de recherche dans la base de données. Définir un objet clé / valeur dans votre niveau d'entreprise qui peut fonctionner avec votre point de vue / présentation.

Je me penche vers l'utilisation d'une représentation de la table pour ce type de données. En fin de compte, si vous avez besoin de saisir les données que vous aurez besoin de le stocker. Aux fins des rapports, il est préférable d'avoir un endroit où vous pouvez dessiner que les données à partir via une clé. Aux fins de normalisation je trouve unique des tables de recherche de but d'être plus facile que d'une des tables de recherche multi-usages.

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

Pourquoi tout le monde veut compliquer les tables de code? Oui, il y a beaucoup d'entre eux, mais ils sont simples, afin de les garder de cette façon. Il suffit de les traiter comme jamais un autre objet. Ton font partie du domaine, afin de les modéliser dans le cadre du domaine, rien de spécial. Si vous ne pas quand ils attributs besoin inevitibly plus ou fonctionnalité, vous devrez défaire tout votre code qui utilise actuellement et le retravailler.

Une table par des cours (pour l'intégrité référentielle et afin qu'ils soient disponibles pour les rapports).

Pour les classes, encore une fois par un bien sûr parce que si j'écris une méthode pour recevoir un « genre » objet, je ne veux pas être en mesure de passer accidentellement un « MarritalStatus »! Laissez l'aide de la compilation vous éliminer l'erreur d'exécution, c'est pourquoi il est là. Chaque classe peut hériter ou simplement contenir une classe ou autre chose, mais table des codes qui est tout simplement une aide de mise en œuvre.

Pour l'interface utilisateur, si elle ne en fait utiliser la table des codes hérités, je suppose que vous pouvez utiliser pour vous aider et juste 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 il vous Wnt à glander un peu dans le modèle d'interface utilisateur, ce n'est pas si mal.

Je voudrais envisager de simplifier cette approche encore plus. Au lieu de 3 tables définissant les codes (Code, et CodeValue) clé de code sur la façon dont une seule table qui contient à la fois les types de code et les valeurs de code? Après tous les types de code sont juste une autre liste de codes.

Peut-être une définition de table comme ceci: 

CREATE TABLE [dbo].[Code](
    [CodeType] [int] NOT NULL,
    [Code] [int] NOT NULL,
    [CodeDescription] [nvarchar](40) NOT NULL,
    [CodeAbreviation] [nvarchar](10) NULL,
    [DateEffective] [datetime] NULL,
    [DateExpired] [datetime] NULL,
CONSTRAINT [PK_Code] PRIMARY KEY CLUSTERED 
(
    [CodeType] ASC,
    [Code] ASC
)
GO

Il pourrait y avoir un dossier racine avec CodeType = 0, Code = 0 qui représente le type de CodeType. Tous les comptes rendus codeType aura un CodeType = 0 et un code> = 1. Voici quelques exemples de données qui pourraient aider à clarifier les choses: 

SELECT CodeType, Code, Description FROM Code

Results:

CodeType    Code    Description
--------    ----    -----------
0           0       Type
0           1       Gender
0           2       Hair Color
1           1       Male
1           2       Female
2           1       Blonde
2           2       Brunette
2           3       Redhead

Une contrainte de vérification pourrait être ajoutée à la table de code pour assurer qu'une CodeType valide est entré dans la table: 

ALTER TABLE [dbo].[Code] WITH CHECK ADD CONSTRAINT [CK_Code_CodeType]   
CHECK (([dbo].[IsValidCodeType]([CodeType])=(1)))
GO

pourrait être définie La IsValidCodeType fonction comme ceci: 

CREATE FUNCTION [dbo].[IsValidCodeType]
(
    @Code INT
)
RETURNS BIT
AS
BEGIN
    DECLARE @Result BIT
    IF EXISTS(SELECT * FROM dbo.Code WHERE CodeType = 0 AND Code = @Code)
        SET @Result = 1
    ELSE
        SET @Result = 0
    RETURN @Result
END
GO

Une question qui a été soulevée est de savoir comment faire en sorte qu'une table avec une colonne de code a une valeur appropriée pour ce type de code. Cela aussi pourrait être exécutée par une contrainte de contrôle à l'aide d'une fonction.

Voici une table de personne qui a une colonne de genre. Il pourrait être une meilleure pratique de nommer toutes les colonnes de code avec la description du type de code (genre dans cet exemple) suivi du code de mot: 

CREATE TABLE [dbo].[Person](   
    [PersonID] [int] IDENTITY(1,1) NOT NULL,
    [LastName] [nvarchar](40) NULL,
    [FirstName] [nvarchar](40) NULL,
    [GenderCode] [int] NULL,
CONSTRAINT [PK_Person] PRIMARY KEY CLUSTERED ([PersonID] ASC)
GO

ALTER TABLE [dbo].[Person] WITH CHECK ADD CONSTRAINT [CK_Person_GenderCode] 
CHECK (([dbo].[IsValidCode]('Gender',[Gendercode])=(1)))
GO

IsValidCode pourrait être défini ainsi: 

CREATE FUNCTION [dbo].[IsValidCode]
(
    @CodeTypeDescription NVARCHAR(40),
    @Code INT
)
RETURNS BIT
AS
BEGIN
    DECLARE @CodeType INT
    DECLARE @Result BIT

    SELECT @CodeType = Code
    FROM dbo.Code
    WHERE CodeType = 0 AND CodeDescription = @CodeTypeDescription

    IF (@CodeType IS NULL)
    BEGIN
        SET @Result = 0
    END
    ELSE
    BEGiN
    IF EXISTS(SELECT * FROM dbo.Code WHERE CodeType = @CodeType AND Code = @Code)
        SET @Result = 1
    ELSE
        SET @Result = 0
    END

    RETURN @Result
END
GO

Une autre fonction peut être créée pour fournir la description du code lors de l'interrogation d'une table qui a une colonne de code. Voici un exemple de interrogeant la table personne: 

SELECT PersonID,
    LastName,
    FirstName,
    GetCodeDescription('Gender',GenderCode) AS Gender
FROM Person

Tout cela a été conçu dans la perspective de la prévention de la prolifération des tables de consultation dans la base de données et fournir une table de consultation. Je ne sais pas si cette conception accomplirait bien dans la pratique.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top