Dati di configurazione: tabella a riga singola vs. tabella nome-valore-coppia

Supponiamo che tu scriva un'applicazione che può essere configurata dall'utente. Per memorizzare questi "dati di configurazione" in un database, vengono comunemente utilizzati due modelli.

1. La tabella a riga singola

     CompanyName  |  StartFullScreen  |  RefreshSeconds  |  ...
   ---------------+-------------------+------------------+--------
     ACME Inc.    |        true       |       20         |  ...
   

2. La tabella nome-valore-coppia

     ConfigOption   |   Value
   -----------------+-------------
    CompanyName     | ACME Inc.
    StartFullScreen | true (or 1, or Y, ...)
    RefreshSeconds  | 20
    ...             | ...
   

Ho visto entrambe le opzioni in natura ed entrambe hanno evidenti vantaggi e svantaggi, ad esempio:

• Le tabelle a riga singola limitano il numero di opzioni di configurazione che è possibile avere (poiché il numero di colonne in una riga è generalmente limitato). Ogni opzione di configurazione aggiuntiva richiede una modifica dello schema DB.
• In una tabella nome-valore-coppia tutto è "tipizzato in modo stringente" (devi codificare / decodificare i tuoi parametri booleani / data / ecc.).
• (molti altri)

Esiste un consenso all'interno della comunità di sviluppo su quale opzione sia preferibile?

Personalmente preferisco le tabelle a riga singola per la maggior parte delle cose. Mentre è vero che è meno flessibile, a meno che non ti aspetti un comportamento dinamico, è perfettamente accettabile aggiungere ulteriori colonne in seguito, se necessario. In un certo senso, è l'equivalente dell'uso di un dizionario / mappa per contenere coppie nome-valore rispetto all'avere membri della classe durante la programmazione. Certo, non è una metafora perfetta, ma molti dei vantaggi e degli svantaggi sono paralleli quando ci pensi.

Quindi useresti un dizionario / mappa sui membri della classe? Probabilmente no a meno che tu non abbia motivo di pensare che la quantità di dati da rappresentare sia completamente adattabile, proprio come avere una tabella di coppie nome-valore.

Generalmente andrei con l'opzione 2 MA avrei più colonne per imporre il tipo di dati

ConfigOption   |   textValue    |   DateValue   |   NumericValue

L'opzione 1 ha il vantaggio aggiuntivo di poter facilmente "scambiare" intere configurazioni aggiungendo una Activecolonna.

Per me, se vai a fila singola o EAV dipende da come vuoi consumarli.

Il potere di EAV è che è possibile aggiungere nuovi dati senza modificare la struttura. Ciò significa che se si desidera un nuovo valore di configurazione, è sufficiente aggiungerlo alla tabella ed estrarlo nel punto desiderato nel codice e non è necessario aggiungere un nuovo campo al dominio, schema, mappatura, query DAL , eccetera.

Il suo difetto è che ha solo la struttura più debole, che richiede di gestire i dati pessimisticamente. Ogni utilizzo di qualsiasi valore di configurazione deve aspettarsi che il valore non sia presente o non sia nel formato corretto e comportarsi di conseguenza quando non lo è. Un valore di configurazione potrebbe non essere analizzabile in un double, in un int o in un char. Potrebbe essere nullo. potrebbe non esserci alcuna riga per il valore. I modi per aggirare questo in genere richiedono l'esistenza di un singolo valore "predefinito" valido per tutti i valori di configurazione di un particolare tipo di codice ( estremamente raro; più spesso il valore predefinito è altrettanto problematico per il consumo del codice come nessuno), oppure per mantenere un dizionario hardcoded di valori predefiniti (che deve cambiare ogni volta che viene aggiunta una nuova colonna, rendendo piuttosto discutibile il vantaggio principale dell'archiviazione EAV).

Una singola riga larga è praticamente l'opposto. Lo si mappa su una singola istanza di un oggetto Configuration con un campo / proprietà per ogni valore di configurazione esistente. Sai esattamente quale tipo dovrebbero essere quei valori in fase di compilazione e "DAL non riesci velocemente" nel DAL se non esiste una colonna di configurazione o non ha un valore del tipo corretto, dandoti un posto dove catturare le eccezioni in base su problemi di recupero / idratazione della configurazione.

Lo svantaggio principale è che è necessario un cambiamento strutturale per ogni nuovo valore; nuova colonna DB, nuova colonna nel DAL (mappatura o query SQL / SP), nuova colonna dominio, tutto necessario per testare correttamente l'utilizzo.

La situazione corretta in cui utilizzare uno di questi è la situazione in cui gli svantaggi sono mitigati. Per me, la maggior parte delle situazioni per la configurazione del codice ha richiesto un'implementazione a riga singola. Questo principalmente perché se stai introducendo un valore di configurazione completamente nuovo che regola il comportamento di alcune parti del tuo programma, devi già modificare il codice per utilizzare il nuovo valore di configurazione; perché non passare all'oggetto config e aggiungere il valore da utilizzare?

In breve, uno schema EAV per l'archiviazione della configurazione non risolve davvero il problema che pretende di risolvere e la maggior parte delle soluzioni alternative ai problemi che presenta violano il DRY.

In particolare per i valori di configurazione, direi: vai con la riga singola. A meno che tu non stia attualmente attraversando uno sviluppo, con che frequenza cambieranno comunque quelle colonne?

Probabilmente è meglio proteggere il tipo di dati dei valori , piuttosto che il codice per l'estensibilità che non si avrà probabilmente nei tempi di inattività tra rilasci di grandi dimensioni (r). Inoltre, aggiungere o rimuovere una singola colonna è la migrazione più semplice che ci sia. Non prevedo un mal di testa quando si crea una nuova opzione di configurazione.

Inoltre, hai detto che "utenti" possono configurare queste opzioni, senza dare un limite. Sono configurazioni per utente? In tal caso, sosterrò ancora più fortemente che le opzioni di configurazione dovrebbero essere nelle colonne - una singola riga per utente. Salverà molti mal di testa di manutenzione in seguito.

Se i tuoi clienti possono elaborare frammenti JSON (che non sono solo matrici e dizionari, ma anche stringhe semplici, numeri, valori booleani, valori null), puoi avere una tabella multi-riga con nome dell'opzione e un valore stringa contenente JSON. Ciò consente di memorizzare anche valori strutturati e il codice per l'elaborazione di questi dovrebbe essere già presente.

Se i tuoi client non sono in grado di elaborare frammenti JSON, ottieni nuovi client.

Pro a riga singola: ben definito. Contro: cambiare la configurazione può essere una seccatura. Migrazioni di DB ecc.

Entity-Value Pro: super flessibile, supporta l'evoluzione della tua configurazione. Contro: integrità referenziale? Ulteriori controlli nel codice per vedere se la proprietà esiste prima di poter fare qualcosa su di essa.

Vorrei adottare l'approccio 2 supportato da un db non relazionale come Mongo. Se c'è qualcosa di cui puoi essere sicuro, il suo cambiamento.

Utilizza entrambi!

Ordina quali opzioni possono avere più istanze e quali opzioni sono generiche.

La tabella a riga singola (configurazioni)

  id  |  company_name  |  start_fullscreen  |  refresh_seconds  |  ...
------+----------------+--------------------+-------------------+-------
  4   |  ACME Inc.     |  true              |  20               |  ...

La tabella nome-valore-coppia (opzioni)

  name             |  value          | update_time  
-------------------+-----------------+--------------
  generic_option_1 |  Option 1 Value | timestamp    
  generic_option_2 |  Option 2 Value | timestamp    
  generic_option_3 |  Option 3 Value | timestamp    
  configuration    |  4              | timestamp    
  ...              |  ...            | ...          

Penso che questo sia più flessibile.