Perché dovresti archiviare un enum in DB?

Ho visto una serie di domande, come questa , che chiedono consigli su come archiviare gli enum in DB. Ma mi chiedo perché dovresti farlo. Quindi diciamo che ho un'entità Personcon un gendercampo e un Genderenum. Quindi, la mia tabella personale ha un genere di colonna.

Oltre all'ovvia ragione per imporre la correttezza, non vedo perché dovrei creare una tabella aggiuntiva genderper mappare ciò che già ho nella mia applicazione. E non mi piace molto avere quella duplicazione.

Facciamo un altro esempio meno denso di concezioni e aspettative. Ho un enum qui, ed è l'insieme delle priorità per un bug.

Quale valore stai memorizzando nel database?

Quindi, potrei essere la memorizzazione 'C', 'H', 'M', e 'L'nel database. O 'HIGH'così via. Questo ha il problema dei dati digitati con stringhe . Esiste un set noto di valori validi e, se non lo memorizzi nel database, può essere difficile lavorarci.

Perché stai memorizzando i dati nel codice?

Hai List<String> priorities = {'CRITICAL', 'HIGH', 'MEDIUM', 'LOW'};qualcosa o qualcosa del genere nel codice. Significa che hai vari mapping di questi dati nel formato corretto (stai inserendo tutti i tappi nel database, ma li stai visualizzando come Critical). Il tuo codice ora è anche difficile da localizzare. La rappresentazione del database dell'idea è stata associata a una stringa memorizzata nel codice.

Ovunque sia necessario accedere a questo elenco, è necessario disporre della duplicazione del codice o di una classe con un gruppo di costanti. Nessuna delle due sono buone opzioni. Non bisogna inoltre dimenticare che esistono altre applicazioni che possono utilizzare questi dati (che possono essere scritti in altre lingue: l'applicazione Web Java ha un sistema di reportistica Crystal Reports utilizzato e un processo batch Perl che inserisce i dati in esso). Il motore di report dovrebbe conoscere l'elenco di dati valido (cosa succede se non c'è nulla contrassegnato in 'LOW'priorità e devi sapere che è una priorità valida per il report?) E il processo batch avrebbe le informazioni su ciò che è valido i valori sono.

Ipoteticamente, potresti dire "siamo un negozio in una sola lingua - tutto è scritto in Java" e abbiamo un singolo .jar che contiene queste informazioni - ma ora significa che le tue applicazioni sono strettamente collegate tra loro e che .jar contenente i dati. Dovrai rilasciare la parte di reportistica e la parte di aggiornamento batch insieme all'applicazione Web ogni volta che si verifica una modifica e sperare che tale versione si svolga senza problemi per tutte le parti.

Cosa succede quando il tuo capo vuole un'altra priorità?

Il tuo capo è venuto oggi. C'è una nuova priorità - CEO. Ora devi andare a cambiare tutto il codice e fare una ricompilazione e ridistribuire.

Con un approccio "enum-in-the-table", aggiorni l'elenco enum per avere una nuova priorità. Tutto il codice che ottiene l'elenco lo estrae dal database.

I dati raramente sono soli

Con le priorità, le chiavi dei dati in altre tabelle che potrebbero contenere informazioni sui flussi di lavoro o chi può impostare questa priorità o altro.

Tornando al genere come menzionato nella domanda per un po ': Il genere ha un link ai pronomi in uso: he/his/hime she/hers/her... e vuoi evitare di codificarlo nel codice stesso. E poi arriva il tuo capo e devi aggiungere che hai il 'OTHER'genere (per renderlo semplice) e devi mettere in relazione questo genere con they/their/them... e il tuo capo vede cosa ha Facebook e ... beh, sì.

Limitando te stesso a un bit di dati tipicamente stringa piuttosto che a una tabella enum, ora hai bisogno di replicare quella stringa in un gruppo di altre tabelle per mantenere questa relazione tra i dati e gli altri bit.

Che dire di altri archivi dati?

Non importa dove lo memorizzi, esiste lo stesso principio.

• Potresti avere un file priorities.propcon l'elenco delle priorità. Hai letto questo elenco da un file di proprietà.

• Potresti avere un database di archivio documenti (come CouchDB ) che ha una voce per enums(e quindi scrivere una funzione di validazione in JavaScript ):

  {
     "_id": "c18b0756c3c08d8fceb5bcddd60006f4",
     "_rev": "1-c89f76e36b740e9b899a4bffab44e1c2",
     "priorities": [ "critical", "high", "medium", "low" ],
     "severities": [ "blocker", "bad", "annoying", "cosmetic" ]
  }
  

• Potresti avere un file XML con un po 'di uno schema:

  <xs:element name="priority" type="priorityType"/>
  
  <xs:simpleType name="priorityType">
    <xs:restriction base="xs:string">
      <xs:enumeration value="critical"/>
      <xs:enumeration value="high"/>
      <xs:enumeration value="medium"/>
      <xs:enumeration value="low"/>
    </xs:restriction>
  </xs:simpleType>
  

L'idea di base è la stessa. L'archivio dati stesso è dove è necessario archiviare e applicare l'elenco di valori validi. Inserendolo qui, è più facile ragionare sul codice e sui dati. Non devi preoccuparti di controllare in modo difensivo quello che hai ogni volta (è maiuscolo o inferiore? Perché c'è un chriticaltipo in questa colonna? Ecc ...) perché sai che cosa stai recuperando dal datastore è esattamente ciò che l'archivio dati si aspetta che invii altrimenti - e puoi interrogare l'archivio dati per un elenco di valori validi.

L'asporto

L'insieme di valori validi sono dati , non codice. È Non c'è bisogno di lottare per DRY codice - ma la questione della duplicazione è che si sta duplicando i dati nel codice, piuttosto che rispettando il suo posto come dati e la memorizzazione in un database.

Semplifica la scrittura di più applicazioni sull'archivio dati ed evita di avere istanze in cui è necessario distribuire tutto ciò che è strettamente accoppiato ai dati stessi, poiché non è stato accoppiato il codice ai dati.

Semplifica il test delle applicazioni perché non è necessario ripetere il test dell'intera applicazione quando CEOviene aggiunta la priorità, poiché non si dispone di alcun codice che si preoccupa del valore effettivo della priorità.

Essere in grado di ragionare sul codice e sui dati indipendentemente l'uno dall'altro semplifica la ricerca e la correzione di bug durante la manutenzione.

Quale di questi pensi sia più probabile che produca errori durante la lettura della query?

select * 
from Person 
where Gender = 1

O

select * 
from Person join Gender on Person.Gender = Gender.GenderId
where Gender.Label = "Female" 

Le persone creano tabelle enum in SQL perché trovano quest'ultima più leggibile, portando a un minor numero di errori nella scrittura e nella gestione di SQL.

Potresti trasformare il genere in una stringa direttamente Person, ma poi dovresti provare ad applicare il caso. È inoltre possibile aumentare l'hit di archiviazione per la tabella e il tempo di query a causa della differenza tra stringhe e numeri interi a seconda di quanto sia fantastico il tuo DB nell'ottimizzare le cose.

Non riesco a credere che la gente non l'abbia ancora menzionato.

Chiavi straniere

Mantenendo l'enum nel database e aggiungendo una chiave esterna nella tabella che contiene un valore enum, si garantisce che nessun codice inserisca mai valori errati per quella colonna. Questo aiuta l'integrità dei tuoi dati ed è il motivo più ovvio per cui IMO dovresti avere tabelle per enumerazioni.

Sono nel campo che è d'accordo con te. Se si mantiene un enumerazione di genere nel codice e un tblGender nel database, è possibile che si verifichino problemi in tempi di manutenzione. Dovrai documentare che queste due entità dovrebbero avere gli stessi valori e quindi qualsiasi modifica apportata a una devi apportare anche all'altra.

Sarà quindi necessario passare i valori enum alle procedure memorizzate in questo modo:

create stored procedure InsertPerson @name varchar, @gender int
    insert into tblPeople (name, gender)
    values (@name, @gender)

Ma pensa come lo faresti se conservassi questi valori in una tabella del database:

create stored procedure InsertPerson @name varchar, @genderName varchar
    insert into tblPeople (name, gender)
    select @name, fkGender
    from tblGender
    where genderName = @genderName --I hope these are the same

Sicuramente i database relazionali sono creati tenendo conto dei join, ma quale query è più facile da leggere?

Ecco un'altra query di esempio:

create stored procedure SpGetGenderCounts
    select count(*) as count, gender
    from tblPeople
    group by gender

Confrontalo con questo:

create stored procedure SpGetGenderCounts
    select count(*) as count, genderName
    from tblPeople
    inner join tblGender on pkGender = fkGender
    group by genderName --assuming no two genders have the same name

Ecco ancora un'altra query di esempio:

create stored procedure GetAllPeople
    select name, gender
    from tblPeople

Nota che in questo esempio, dovresti convertire la cella di genere nei tuoi risultati da un int a un enum. Queste conversioni sono comunque facili. Confrontalo con questo:

create stored procedure GetAllPeople
    select name, genderName
    from tblPeople
    inner join tblGender on pkGender = fkGender

Tutte queste query sono più piccole e più gestibili quando si considera l'idea di mantenere le definizioni enum fuori dal database.

Vorrei creare una tabella Genders per il motivo che può essere utilizzata nell'analisi dei dati. Potrei cercare tutte le persone di sesso maschile o femminile nel database per generare un rapporto. Più modi puoi visualizzare i tuoi dati, più facile sarà scoprire informazioni di tendenza. Ovviamente, questa è un'enumerazione molto semplice, ma per enumerazioni complesse (come i paesi del mondo o gli stati), rende più semplice generare report specializzati.

Innanzitutto è necessario decidere se il database verrà utilizzato solo da un'applicazione o se è possibile che vengano utilizzate da più applicazioni. In alcuni casi un database non è altro che un formato di file per un'applicazione (i database SQLite possono spesso essere utilizzati in questo senso). In questo caso, duplicare un po 'la definizione di enum come tabella può spesso andare bene e può avere più senso.

Tuttavia, non appena si desidera considerare la possibilità di avere più applicazioni che accedono al database, una tabella per l'enum ha molto senso (le altre risposte spiegano perché in modo più dettagliato). L'altra cosa da considerare è che tu o un altro sviluppatore desideriate esaminare i dati del database non elaborati. In tal caso, questo può essere considerato un altro utilizzo dell'applicazione (solo uno in cui l'indicatore di laboratorio è SQL non elaborato).

Se hai l'enum definito nel codice (per un codice più pulito e il controllo del tempo di compilazione) e una tabella nel database, consiglierei di aggiungere test unitari per verificare che i due siano sincronizzati.

Quando si dispone di un'enumerazione di codice utilizzata per guidare la logica aziendale nel codice, è comunque necessario creare una tabella per rappresentare i dati nel DB per i numerosi motivi descritti sopra / sotto. Ecco alcuni suggerimenti per assicurare che i valori del tuo DB rimangano sincronizzati con i valori del codice:

1. Non rendere il campo ID sulla tabella una colonna Identità. Includi ID e descrizione come campi.

2. Fare qualcosa di diverso nella tabella per aiutare gli sviluppatori a sapere che i valori sono semi-statici / legati a un'enumerazione di codice. In tutte le altre tabelle di ricerca (di solito dove gli utenti possono aggiungere valori) Di solito ho un LastChangedDateTime e un LastChangedBy, ma non averli nelle tabelle relative all'enum mi aiuta a ricordare che sono modificabili solo dagli sviluppatori. Documentalo.

3. Creare un codice di verifica che controlli che ogni valore nell'enumerazione sia nella tabella corrispondente e che solo quei valori siano nella tabella corrispondente. Se disponi di "test di integrità" per applicazioni automatiche che eseguono post-build, lì. In caso contrario, eseguire automaticamente il codice all'avvio dell'applicazione ogni volta che l'applicazione è in esecuzione nell'IDE.

4. La produzione genera script SQL che fanno lo stesso, ma dall'interno del DB. Se creati correttamente, aiuteranno anche le migrazioni dell'ambiente.

Dipende anche da chi accede ai dati. Se hai solo un'applicazione che potrebbe andare bene. Se si aggiunge un data warehouse o un sistema di reporting. Dovranno sapere cosa significa quel codice, qual è la versione redable umana del codice.

Di solito, la tabella dei tipi non viene duplicata come enum nel codice. È possibile caricare la tabella dei tipi in un elenco memorizzato nella cache.

Class GenderList

   Public Shared Property UnfilteredList
   Public Shared Property Male = GetItem("M")
   Public Shared Property Female = GetItem("F")

End Class

Spesso, il tipo va e viene. Avresti bisogno di una data per quando è stato aggiunto il nuovo tipo. Sapere quando è stato rimosso un tipo specifico. Visualizzalo solo quando necessario. Cosa succede se un cliente vuole "transgender" come genere, ma altri clienti no? Tutte queste informazioni sono meglio archiviate nel database.