Enumerazioni DB vs Enumerazioni app vs Tabelle di ricerca

3

Abbiamo recentemente avviato un progetto e durante il processo di progettazione abbiamo alcuni argomenti tra i membri del team. Dobbiamo fare i conti con le enumerazioni quindi abbiamo finito con tre scelte.

  1. avere le enumerazioni come normali enum nel database
  2. avere le enumerazioni all'interno dell'applicazione e isolate dal database. Tenerli solo nel livello App.
  3. Archivia le enumerazioni in diverse tabelle nel DB

Che cosa pensi e perché? Dalla mia esperienza, scelgo il 3 °, poiché non ho mai visto che il costo dei join sia davvero un problema. E se usi un ORM, il costo dei join non è quasi nulla a causa del caching.

    
posta pik4 12.09.2018 - 09:15
fonte

4 risposte

2

Suggerirei tabelle di database, una per lista.

Le enumerazioni esistono per elencare i valori consentiti per uno o più attributi. Probabilmente vorrai applicare queste restrizioni anche all'interno del database. Per questo hai bisogno di chiavi esterne e per quelle hai bisogno di avere le enumerazioni nelle tabelle. È meglio avere una tabella per enumerazione in modo che le chiavi esterne siano semplici da definire e ovvie nel loro intento.

Avere tabelle e chiavi esterne non significa necessariamente un join in ogni lettura. Se le enumerazioni sono stabili nel tempo e hanno codici brevi e significativi, questi codici possono essere propagati alle tabelle di riferimento. Diciamo che abbiamo un'enumerazione di direzioni cardinali: Nord, Sud, Est e Ovest. Questi sono stabili nel tempo. Hanno codici brevi e significativi: N, S, E & W. Chi vede un codice capirà il significato dato al contesto. Quindi avere il codice della chiave esterna fa riferimento al codice della singola lettera farà il lavoro e può omettere un join. Al contrario, il design abituale avrà una chiave surrogata nella tabella di enumerazione. Poiché questo è in genere un numero privo di significato, i join saranno comunque necessari per restituire valori comprensibili all'uomo.

Una volta che hai le enumerazioni nelle tabelle, ha senso ripeterle nell'applicazione? Ripeterli come codice aggiuntivo sarebbe un errore. Ci sarebbero due liste - una nell'app, una nel database - che devono essere mantenute sincronizzate. Tale duplicazione è una fonte comune di errore. Per avere i valori memorizzati nella cache dell'applicazione, al contrario della lettura della tabella ogni volta che sono richiesti i valori dell'enumerazione, può essere utile. Dipende dall'app, con quale frequenza vengono citati questi elenchi, quanta memoria è disponibile ecc. Ecc. Poiché stai considerando di codificare i valori, riavviare l'app per raccogliere nuovi valori dal database non dovrebbe essere un problema, anche se sono possibili altre soluzioni.

L'utilizzo delle enumerazioni di database potrebbe funzionare se si è certi che l'elenco sia a valore singolo e non si ridurrà mai. Rimuovere un valore di enumerazione è complicato. L'aggiunta di nuovi valori richiede privilegi elevati. Proprietà aggiuntive (ad esempio (direzione, codice, rilevamento) = (Sud, S, 180)) non sono possibili.

    
risposta data 19.09.2018 - 01:33
fonte
1

C'è una dicotomia tra due punti di vista opposti

  1. Vuoi la possibilità di aggiungere nuovi elementi al set senza ricompilare l'applicazione - questo favorisce una tabella di ricerca nel database.
  2. Esiste una logica aziendale basata sul set all'interno dell'applicazione compilata. per es.

    if (Client.ClientType == ClientType.Important)
        DoSomethingSpecial();
    

    Questo favorisce un enum all'interno dell'applicazione.

Devi decidere quale è più importante per il tuo caso. Avere sia una tabella di ricerca che una enumerazione, potrebbe sembrare una sicurezza per le cinture e le cinghie, ma può presto causare problemi se non riescono ad andare oltre.

    
risposta data 19.09.2018 - 14:28
fonte
0

Se il costo dello storage è insignificante in ciascun caso, come suggerito, il determinante verrebbe probabilmente destinato a costi di sviluppo e manutenzione. Il che significa considerare le risorse disponibili e preferire le opzioni più semplici e familiari.

    
risposta data 19.09.2018 - 01:59
fonte
0

Puoi memorizzare queste enumerazioni come valori interi.

  • Facile da fare, a basso sforzo
  • Manutenzione ridotta, nessun problema di sincronizzazione dei dati, nessun problema di distribuzione
  • Può aggiungere CHECK MyCol BETWEEN 1 AND 3
  • Miglior rendimento

Se questa semplice soluzione soddisfa le tue esigenze, allora è la strada da percorrere.

A volte, è necessario creare tabelle enum. Ad esempio, potresti aver bisogno di un valore associato in una query. Forse hai un enum per i tipi di clienti e vuoi una query che utilizza l'importo massimo dell'ordine per tipo di cliente. Quindi, è molto conveniente avere quei dati come dati di riferimento statici disponibili nel database per l'adesione.

Non creare con entusiasmo quei tavoli. Fallo quando richiesto. È facile eseguire l'upgrade dalla colonna intera alla soluzione di enum table.

    
risposta data 19.09.2018 - 14:13
fonte