migliori pratiche con tabelle di codice o di ricerca

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

Domanda

[UPDATE] approccio scelto è al di sotto, come una risposta a questa domanda

Ciao,

'ho cercato in giro in questo argomento, ma non riesco davvero a trovare ciò che sto cercando ...

Con le tabelle di codice intendo: cose del genere 'stato maritial', il sesso, gli stati legali o sociali specifici ... proprietà Più specificamente, questi tipi sono solo fissati e gli articoli non sono in procinto di cambiare presto (ma potrebbe). Proprietà essendo un ID, un nome e una descrizione.

Mi chiedo come gestire questi migliore nelle seguenti tecnologie:

  • nel database (più tabelle, una tabella con tasti di codice diversi ...?)

  • la creazione di classi (probabilmente qualcosa come ereditare ICode con ICode.Name e ICode.Description)

  • creazione della vista / presentatore per questo: ci dovrebbe essere una schermata contenente tutti loro, quindi un elenco dei tipi (sesso, stato maritial ...), e poi un elenco di valori per quel tipo con un nome e descrizione per ogni voce nel valore-list.

Queste sono le cose che appaiono in ogni singolo progetto, quindi ci deve essere qualche best practice su come gestire questi ...

Per la cronaca, io non sono davvero appassionato di utilizzare enumerazioni per queste situazioni ... Qualsiasi argomento sull'uso loro qui sono i benvenuti.

[FOLLOW UP]

Ok, ho ottenuto una bella risposta da CodeToGlory e Ahsteele. Cerchiamo di affinare questa domanda.

dire che non stiamo parlando di sesso o di stato maritial, valori wich saranno sicuramente non cambia, ma di "roba" che hanno un nome e una descrizione, ma niente di più. Per esempio:. Stati sociali, gli stati giuridica

Interfaccia utente: Voglio solo schermo per questo. Listbox con tipi possibe NameAndDescription (mi limiterò a loro che chiamo), casella di riepilogo con i valori possibili per selezionato il tipo NameAndDescription, e poi un nome e una descrizione di campo per il tipo selezionato NameAndDescription Item.

Come può essere gestito in View & presentatori? Trovo la difficoltà qui che i tipi NameAndDescription avrebbero quindi bisogno di essere estratto dal nome della classe?

DB: Quali sono pro / contro per multiplo vs singole tabelle di ricerca?

È stato utile?

Soluzione 3

Ho deciso di andare con questo approccio: 

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

Dove:

  • CodeKeyManager può recuperare CodeKeys da DB (CodeKey = StatoCivile)
  • Codice è una classe piena di costanti, tornando così stringhe Code.MaritalStatus = "StatoCivile". Queste costanti mappano al tavolo CodeKey> CodeKeyName
  • Nel database, ho 2 tabelle:
    • CodeKey con Id, CodeKeyName
    • CodeValue con CodeKeyId, NomeValore, ValoreDescrizione

DB:

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

Codice Classe: 

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

Classe CodeKey: 

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; }

}

trovo di gran lunga il modo più semplice ed efficiente:

  • Tutti i codici-dati possono essere visualizzati in modo identico (nella stessa vista / presentatore)
  • non ho bisogno per creare tabelle e classi per ogni tavolo codice che è a venire
  • ma posso ancora li uscire dalla banca dati facilmente e utilizzarli facilmente con le costanti CodeKey ...
  • NHibernate in grado di gestire facilmente questo troppo

L'unica cosa che sto ancora valutando sta gettando fuori del GUID Id e l'utilizzo di stringhe codici (nchar) per l'usabilità nella logica di business.

Grazie per le risposte! Se ci sono osservazioni su questo approccio, si prega di fare!

Altri suggerimenti

Utilizzando database driven tavoli codice può molto utile. È possibile fare cose come definire la vita dei dati (utilizzando inizio e di fine), aggiungere i dati alla tabella in tempo reale, in modo da non è necessario distribuire il codice, ed è possibile consentire agli utenti (con i giusti privilegi ovviamente) aggiungere i dati attraverso le schermate di amministrazione.

mi sento di raccomandare sempre utilizzando una chiave autonumber primaria piuttosto che il codice o descrizione. Questo permette di utilizzare più codici (con lo stesso nome ma diverse descrizioni) in diversi periodi di tempo. Inoltre la maggior parte degli amministratori di database (nella mia esperienza), piuttosto usano l'autonumber le chiavi primarie di testo base.

Vorrei usare una singola tabella per ogni lista codificata. È possibile inserire più codici tutto in una tabella che non si riferiscono (utilizzando una matrice di sorta), ma che diventa disordinato e ho trovato solo un paio di situazioni in cui è stato anche utile.

Un paio di cose qui:

  1. Usa enumerazioni che sono esplicitamente chiaro e non cambieranno. Ad esempio, StatoCivile, di genere ecc.

  2. Uso delle tabelle per gli articoli che non sono fissati come sopra e possono cambiare, aumentare / diminuire nel tempo.

E 'molto tipico di avere tabelle di ricerca nel database. Definire un / oggetto valore chiave nel vostro livello business che può funzionare con il vostro vista / presentazione.

mi chino verso l'utilizzo di una rappresentazione tavolo per questo tipo di dati. In definitiva se avete la necessità di catturare i dati avrete la necessità di conservarlo. Ai fini dei rapporti è meglio avere un posto si può trarre che i dati da via una chiave. Ai fini della normalizzazione trovo singole tabelle scopo di ricerca per essere più facile di un multi-purpose le tabelle di ricerca.

Detto enumerazioni funzionano abbastanza bene per le cose che non cambieranno come genere ecc.

Perché tutti vogliono complicare tabelle di codice? Sì, ci sono un sacco di loro, ma sono semplici, in modo da tenerli in quel modo. Proprio li trattano come mai altro oggetto. Thy sono parte del dominio, in modo da modellare come parte del dominio, niente di speciale. Se non quando inevitibly bisogno di più attributi o funzionalità, si dovrà annullare tutto il codice che attualmente usa e rielaborarlo.

Una tabella per ciascuna naturalmente (per l'integrità referenziale e in modo che siano disponibili per la segnalazione).

Per le classi, di nuovo uno per, naturalmente, perché se scrivo un metodo per ricevere un oggetto "di genere", io non voglio essere in grado di passare accidentalmente un "MarritalStatus"! Lasciate che l'aiuto di compilazione estirpare errore di runtime, è per questo che la sua lì. Ogni classe può semplicemente ereditare o contengono una classe tabella dei codici o qualsiasi altra cosa, ma questo è semplicemente un aiuto implementazione.

Per l'interfaccia utente, se lo fa, infatti, utilizzare la tabella dei codici ereditato, suppongo che si possa utilizzare che per aiutarvi e solo mantenerlo in un'interfaccia utente.

In linea di massima, non rovinare il modello di database, non si scherza il modello di business, ma si Wnt a vite in giro un po 'nel modello di interfaccia utente, che non è poi così male.

Mi piacerebbe prendere in considerazione la semplificazione questo approccio ancora di più. Invece di 3 tavoli che definiscono codici (Codice, CodeKey e CodeValue) Che ne dici solo una tabella che contiene entrambi i tipi di codice ed i valori di codice? Dopo che tutti i tipi di codici sono solo un altro elenco di codici.

Forse una definizione di tabella come questa: 

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

Ci potrebbe essere un record radicolare con CodeType = 0, codice = 0 che rappresenta il tipo per CodeType. Tutti i record CODETYPE avrà un CodeType = 0 e un codice> = 1. Ecco alcuni dati di esempio che potrebbe aiutare chiarire le cose: 

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

Un vincolo di controllo potrebbe essere aggiunto alla tabella di codice per garantire che un CodeType valida viene inserito nella tabella: 

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

L'IsValidCodeType funzione potrebbe essere definita in questo modo: 

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

Una questione che è stata sollevata è il modo per garantire che una tabella con una colonna di codice ha un valore appropriato per quel tipo di codice. Anche questo potrebbe essere eseguita da un vincolo di controllo utilizzando una funzione.

Ecco una tabella persona che ha una colonna di genere. Potrebbe essere una buona pratica di nominare tutte le colonne di codice con la descrizione del tipo di codice (di genere, in questo esempio) seguito dal Codice parola: 

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 potrebbe essere definita in questo modo: 

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

Un'altra funzione potrebbe essere creato per fornire la descrizione di codice quando si interroga una tabella che ha una colonna codice. Ecco un esempio di interrogare la tabella Person: 

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

questo è stato concepito dal punto di vista di impedire la proliferazione di tabelle di ricerca nel database e fornendo una tabella di ricerca. Non ho idea se questo disegno si comporta bene nella pratica.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top