melhores práticas com código ou de pesquisa de tabelas

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

Pergunta

[UPDATE] abordagem escolhida é inferior, como uma resposta a esta pergunta

Oi,

Eu tenho procurado em torno deste assunto, mas eu realmente não posso encontrar o que estou procurando ...

Com tabelas de códigos quero dizer: coisas como 'estado maritial', sexo, estados legais ou sociais específicos ... Mais especificamente, estes tipos têm apenas definir as propriedades e os itens não estão prestes a mudar em breve (mas poderia). Propriedades ser um ID, um nome e uma descrição.

Eu estou querendo saber como lidar com estes melhor nas seguintes tecnologias:

  • no banco de dados (várias tabelas, uma tabela com teclas de código diferente ...?)

  • criar as classes (provavelmente algo como herdar ICODE com ICode.Name e ICode.Description)

  • criando a vista / apresentador para isso: deve haver uma tela contendo todos eles, então uma lista dos tipos (sexo, estado maritial ...), e, em seguida, uma lista de valores para esse tipo de um nome e descrição para cada item na lista valor.

Estas são coisas que aparecem em cada projeto, então deve haver algum melhores práticas sobre como lidar com estes ...

Para o registro, eu não sou realmente gostam de usar enums para estas situações ... Todos os argumentos sobre a usá-los aqui são bem-vindos também.

[ACOMPANHAMENTO]

Ok, eu comecei uma resposta agradável por CodeToGlory e Ahsteele. Vamos refinar esta questão.

dizer que nós não estamos falando de sexo ou estado maritial, wich valores definitivamente não vai mudar, mas de "coisas" que têm um nome e uma descrição, mas nada mais. Por exemplo: estatutos sociais, estatutos jurídicos

.

UI: Eu quero apenas uma tela para isso. Caixa de listagem com tipos possibe NameAndDescription (vou chamá-los assim), caixa de listagem com os valores possíveis para o tipo NameAndDescription selecionada e um nome e descrição de campo para o selecionado NameAndDescription tipo de item.

Como isso pode ser tratado em Ver e apresentadores? Acho que a dificuldade aqui que precisaria então os Tipos NameAndDescription a ser extraído do nome da classe?

DB: Quais são pro / contras para múltiplos vs tabelas de pesquisa individuais?

Foi útil?

Solução 3

Eu decidi ir com esta abordagem: 

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

Onde:

  • CodeKeyManager pode recuperar CodeKeys de DB (CodeKey = situação conjugal)
  • Code é uma classe cheia de constantes, retornando cordas tão Code.MaritalStatus = "situação conjugal". Essas constantes são mapeados para a tabela de CodeKey> CodeKeyName
  • No banco de dados, eu tenho 2 tabelas:
    • CodeKey com Id, CodeKeyName
    • CodeValue com CodeKeyId, ValueName, ValorDescrição

DB:

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

Código de Classe: 

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

Class CodeKey: 

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

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

Class CodeValue: 

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

    public CodeKey Code { get; set; }

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

}

I encontrar de longe a maneira mais fácil e eficiente:

  • todo o código-de dados pode ser visualizada de um modo idêntico (na mesma vista / apresentador)
  • Eu não preciso para criar tabelas e classes para cada mesa código que está por vir
  • Mas eu ainda posso tirá-los do banco de dados facilmente e usá-los facilmente com a CodeKey constantes ...
  • NHibernate pode lidar com isso facilmente demasiado

A única coisa que eu ainda estou considerando é jogar fora do GUID Id e usando string (nchar) códigos para a usabilidade na lógica de negócios.

Obrigado pelas respostas! Se houver quaisquer observações sobre esta abordagem, por favor!

Outras dicas

Usando tabelas de códigos banco de dados orientado pode muito útil. Você pode fazer coisas como definir a vida dos dados (usando datas de início e fim), adicionar dados para a mesa em tempo real, para que você não tem que implantar código, e você pode permitir que os usuários (com os privilégios certas, é claro) adicionar dados através de telas de administração.

Eu recomendaria sempre usando uma chave primária autonumber em vez do código ou descrição. Isso permite que você use vários códigos (com o mesmo nome mas diferentes descrições) ao longo de diferentes períodos de tempo. Além disso, a maioria dos DBAs (na minha experiência), em vez usar o autonumber sobre o texto base chaves primárias.

Gostaria de usar uma única tabela por lista codificada. Você pode colocar vários códigos todos em uma tabela que não se relacionem (usando uma matriz de tipos), mas que fica confuso e eu só encontrei um par de situações onde era mesmo útil.

Algumas coisas aqui:

  1. Use Enumerations que são explicitamente claro e não vai mudar. Por exemplo, situação conjugal, Sexo etc.

  2. Use lookup tabelas para itens que não são fixos como acima e pode mudar, aumentar / diminuir ao longo do tempo.

É muito típico para ter lookup tabelas no banco de dados. Definir um objeto de chave / valor em sua camada de negócios que pode trabalhar com a sua visão / apresentação.

Eu inclinar-se para utilizar uma representação de tabela para este tipo de dados. Em última análise, se você tem uma necessidade para capturar os dados que você tem uma necessidade de armazená-lo. Para fins de divulgação, é melhor ter um lugar que você pode chamar que os dados de através de uma chave. Para fins de normalização I encontrar tabelas de pesquisa propósito único a ser mais fácil do que tabelas de pesquisa multi-purpose.

Dito enumerações funcionar muito bem para as coisas que não vai mudar como o gênero etc.

Por que todos querem tabelas de códigos complicar? Sim, existem muitos deles, mas eles são simples, assim mantê-los dessa forma. Basta tratá-los como nunca outro objeto. Tua fazem parte do domínio, para modelá-los como parte do domínio, nada de especial. Se não o fizer, quando inevitibly precisar de mais atributos ou funcionalidade, você terá que desfazer todo o seu código que atualmente usa-lo e refazê-la.

Um quadro por claro (para a integridade referencial e assim que eles estão disponíveis para relatórios).

Para as classes, novamente um por, claro, porque se eu escrever um método para receber um objeto "Sexo", eu não quero ser capaz de passá-lo acidentalmente um "MarritalStatus"! Deixe a compilação ajuda a eliminar erro de execução, é por isso que a sua existência. Cada classe pode simplesmente herdar ou conter uma classe tabela de códigos ou qualquer outra coisa, mas isso é simplesmente um auxiliar de implementação.

Para a interface do usuário, se ele faz em uso fato da tabela de códigos herdada, eu suponho que você poderia usar isso para ajudá-lo para fora e apenas mantê-lo em um interface do usuário.

Como regra geral, não estrague o modelo de banco de dados, não atrapalhar o modelo de negócio, mas você wnt para parafuso de volta um pouco no modelo de interface do usuário, que não é tão ruim.

Eu gostaria de considerar a simplificação essa abordagem ainda mais. Em vez de 3 tabelas que definem códigos (Código, CodeKey e CodeValue) Como cerca de apenas uma tabela que contém ambos os tipos de código e os valores de código? Depois de todos os tipos de códigos são apenas uma outra lista de códigos.

Talvez uma definição tabela como esta: 

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

Pode haver um registro de raiz com CodeType = 0, código = 0, que representa o tipo de CodeType. Todos os registros CodeType terá um CodeType = 0 e um Código> = 1. Aqui está alguns dados da amostra que possa ajudar a esclarecer as coisas: 

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

Uma restrição de verificação pode ser adicionado à tabela de código para garantir que uma CodeType válido é inserido na tabela: 

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

A função IsValidCodeType poderia ser definido assim: 

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

Uma questão que tem sido levantada é como garantir que uma tabela com uma coluna de código tem um valor adequado para esse tipo de código. Isso também poderia ser aplicada por uma restrição de verificação usando uma função.

Aqui está uma tabela Pessoa que tem uma coluna de gênero. Poderia ser uma melhor prática para nomear todos os campos de código com a descrição do tipo de código (Sexo neste exemplo), seguido pela palavra código: 

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 poderia ser definido desta maneira: 

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

Outra função poderia ser criado para fornecer a descrição do código ao consultar uma tabela que tem uma coluna de código. Aqui está um exemplo de consultar a tabela Pessoa: 

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

Isso tudo foi concebido a partir da perspectiva de prevenir a proliferação de tabelas de pesquisa no banco de dados e fornecendo uma tabela de pesquisa. Eu não tenho idéia se este projeto iria realizar bem na prática.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top