Domanda

Qual è il metodo preferito dalle persone per archiviare i dati di configurazione dell'applicazione in un database. Da quando ho fatto questo in passato, ho utilizzato due modi per farlo.

  1. È possibile creare una tabella in cui memorizzare coppie chiave / valore, dove chiave è il nome dell'opzione di configurazione e valore è il suo valore. Pro di questo è l'aggiunta di nuovi valori è facile e puoi usare le stesse routine per impostare / ottenere dati. I lati negativi sono i dati non tipizzati come valore.
  2. In alternativa, puoi codificare una tabella di configurazione, con ogni colonna come nome del valore e tipo di dati. L'aspetto negativo di questo è la maggiore manutenzione che imposta nuovi valori, ma consente di avere dati digitati.

Avendo usato entrambi, le mie preferenze si trovano con la prima opzione come più veloce per impostare le cose, tuttavia è anche più rischioso e può ridurre le prestazioni (leggermente) quando si cercano i dati. Qualcuno ha metodi alternativi?

Aggiorna

È necessario archiviare le informazioni in un database perché, come indicato di seguito, potrebbero esserci più istanze del programma che richiedono la configurazione allo stesso modo, nonché procedure memorizzate che utilizzano potenzialmente gli stessi valori.

È stato utile?

Soluzione

Puoi espandere l'opzione 1 per avere una terza colonna, fornendo un tipo di dati. La tua applicazione può utilizzare questa colonna del tipo di dati per trasmettere il valore.

Ma sì, andrei con l'opzione 1, se i file di configurazione non sono un'opzione. Un altro vantaggio dell'opzione 1 è che puoi leggerlo in un oggetto Dizionario (o equivalente) per usarlo nella tua applicazione molto facilmente.

Altri suggerimenti

Poiché in genere la configurazione può essere archiviata in un file di testo, il tipo di dati stringa deve essere più che sufficiente per memorizzare i valori di configurazione. Se stai usando una lingua gestita, è il codice a sapere quale dovrebbe essere il tipo di dati, non il database.

Ancora più importante, considera queste cose con la configurazione:

  • Gerarchia : ovviamente, la configurazione trarrà vantaggio da a gerarchia
  • Controllo delle versioni : considera il vantaggio di poter ripristinare la configurazione in vigore a una determinata data.
  • Distribuzione : qualche volta, potrebbe essere bello poter raggruppare un'applicazione. Alcune proprietà dovrebbero probabilmente essere locali per ciascun nodo in un cluster.
  • Documentazione : a seconda che tu abbia uno strumento web o qualcosa del genere, è probabilmente utile archiviare la documentazione relativa a una proprietà vicino al codice che la utilizza. (Le annotazioni del codice sono molto utili per questo.)
  • Notifica : in che modo il codice saprà che è stata apportata una modifica da qualche parte nel repository di configurazione?

Personalmente, mi piace un modo invertito di gestire la configurazione, in cui le proprietà di configurazione vengono iniettate nei moduli che non sanno da dove provengono i valori. In questo modo, il sistema di gestione della configurazione può essere molto complesso o molto semplice a seconda delle esigenze (attuali).

Uso l'opzione 1.

Sembra eccessivo usare il DB per i dati di configurazione.

MODIFICA (scusa troppo a lungo per la casella di commento): Ovviamente non esistono regole rigide su come implementare qualsiasi parte del programma. Per ragioni di discussione, i cacciaviti a taglio funzionano su alcune viti a croce! Immagino di aver giudicato troppo presto prima di sapere qual è il tuo scenario.

Il database relazionale eccelle in un enorme archivio di dati che ti consente di archiviare, aggiornare e recuperare rapidamente, quindi se i tuoi dati di configurazione vengono aggiornati e letti costantemente, allora usa sicuramente db.

Un altro scenario in cui db può avere senso è quando si dispone di una server farm in cui si desidera che il database memorizzi la configurazione centrale, ma quindi è possibile fare lo stesso con un'unità di rete condivisa che punta al file di configurazione xml.

Il file XML è migliore quando la configurazione è gerarchicamente strutturata. Puoi facilmente organizzare, localizzare e aggiornare ciò di cui hai bisogno e, a vantaggio del bonus, puoi controllare la versione del file di configurazione insieme al tuo codice sorgente!

Tutto sommato, dipende da come vengono utilizzati i dati di configurazione.

Questo conclude la mia opinione con una conoscenza limitata della tua candidatura. Sono sicuro che puoi prendere la decisione giusta.

Suppongo che questo sia più un sondaggio, quindi dirò l'approccio della colonna (opzione 2). Tuttavia dipenderà dalla frequenza con cui la tua configurazione cambia, dalla sua dinamica e dalla quantità di dati presenti, ecc.

Utilizzerei sicuramente questo approccio per le configurazioni / preferenze degli utenti, ecc.

Il mio progetto utilizza una tabella di database con quattro colonne:

  1. ID [pk]
  2. Ambito ('Applicazione' predefinita)
  3. Impostazione
  4. Valore

Le impostazioni con un ambito di 'Applicazione' sono impostazioni globali, come Numero massimo di utenti simultanei.

Ogni modulo ha il proprio ambito di applicazione; quindi i nostri ResultsLoader e UserLoader hanno ambiti diversi, ma entrambi hanno un'impostazione denominata "inputPath".

I valori predefiniti vengono forniti nel codice sorgente o vengono iniettati tramite il nostro contenitore IoC. Se non viene iniettato o fornito alcun valore nel database, viene utilizzato il valore predefinito dal codice (se presente). Pertanto, le impostazioni predefinite non vengono mai archiviate nel database.

Questo funziona abbastanza bene per noi. Ogni volta che eseguiamo il backup del database otteniamo una copia della configurazione che è abbastanza utile. I due sono sempre sincronizzati.

Vai con l'opzione 2. L'opzione 1 è davvero un modo per implementare un database sopra un database, e questo è un antipattern ben noto, che ti darà problemi a lungo termine.

Posso pensare ad almeno altri due modi:

(a) Crea una tabella con colonne chiave, valore stringa, valore data, valore int, valore reale. Lascia i tipi non utilizzati NULL.

(b) Utilizza un formato di serializzazione come XML, YAML o JSON e archivia tutto in un BLOB.

Dove memorizzi le impostazioni di configurazione necessarie alla tua app per connettersi al database?

Perché non archiviare anche le altre informazioni di configurazione lì?

Vorrei andare con l'opzione 1, a meno che il numero di opzioni di configurazione fosse MOLTO piccolo (sette o meno)

Nella mia azienda, stiamo lavorando sull'utilizzo dell'opzione 1 (una semplice tabella simile a un dizionario) con una svolta. Stiamo permettendo la sostituzione di stringhe usando token che contengono il nome della variabile di configurazione da sostituire.

Ad esempio, la tabella potrebbe contenere righe ('stringa di connessione al database', 'jdbc: //% host% ...') e ('host', 'foobar'). Incapsulare ciò con un servizio semplice o un livello di procedura memorizzata consente una configurazione ricorsiva estremamente semplice, ma flessibile. Supporta la nostra necessità di avere più ambienti isolati (sviluppo, test, prod, ecc.)

Ho usato sia 1 che 2 in passato e penso che siano entrambe soluzioni terribili. Penso che l'opzione 2 sia migliore perché consente di digitare, ma è molto più brutta dell'opzione 1. Il problema più grande che ho con entrambi è il controllo delle versioni del file di configurazione. È possibile eseguire la versione SQL ragionevolmente bene utilizzando i sistemi di controllo della versione standard, ma l'unione delle modifiche è generalmente problematica. Data l'opportunità di farlo "giusto", probabilmente creerei un gruppo di tabelle, una per ogni tipo di parametro di configurazione (non necessariamente per ogni parametro stesso), ottenendo così il vantaggio della digitazione e il vantaggio della chiave / paradigma del valore ove appropriato. Puoi anche implementare strutture più avanzate in questo modo, come elenchi e gerarchie, che saranno quindi direttamente interrogabili dall'app invece di dover caricare la configurazione e trasformarla in qualche modo in memoria.

Io voto per l'opzione 2. Facile da capire e mantenere.

L'opzione 1 è utile per una posizione di archiviazione centrale facilmente espandibile. Oltre ad alcuni dei fantastici suggerimenti di colonne di persone come RB, Hugo e elliott, potresti anche prendere in considerazione:

Includi un flag di impostazione globale / utente con un campo utente o persino un campo utente / macchina (per le impostazioni del tipo di interfaccia utente specifiche della macchina).

Questi, ovviamente, possono essere archiviati in un file locale, ma poiché si utilizza comunque il database, ciò li rende disponibili per l'aliasing di un utente durante il debug, il che può essere importante se il bug è relativo alle impostazioni. Consente inoltre a un amministratore di gestire le impostazioni quando necessario.

Uso un mix di opzioni 2 e colonne XML in SQL Server. È inoltre possibile che non si desideri aggiungere un vincolo di controllo per mantenere la tabella su una riga.

CREATE TABLE [dbo].[MyOption] (
  [GUID] uniqueidentifier CONSTRAINT [dfMyOptions_GUID] DEFAULT newsequentialid()  ROWGUIDCOL NOT NULL,
  [Logo] varbinary(max) NULL,
  [X] char(1)  CONSTRAINT [dfMyOptions_X] DEFAULT 'X' NOT NULL,
  CONSTRAINT [MyOptions_pk] PRIMARY KEY CLUSTERED ([GUID]),
  CONSTRAINT [MyOptions_ck] CHECK ([X]='X')
)

per le impostazioni che non hanno alcuna relazione con alcuna tabella db, probabilmente sceglierei l'approccio EAV se hai bisogno del db per lavorare con i valori. altrimenti un valore di campo serializzato è buono se è davvero solo un negozio per il codice dell'app.

ma che dire di un formato per un singolo campo per memorizzare più impostazioni di configurazione che verranno utilizzate dal db?

come un campo per utente che contiene tutte le impostazioni relative alla visualizzazione della bacheca (come ordinamento predefinito, argomenti bloccati, ecc.) e forse un altro con tutte le impostazioni per il tema (come colore del testo, colore bg, ecc. .)

La memorizzazione di gerarchie e documenti in un DB relazionale è una follia. In primo luogo o devi distruggerli, solo per ricombinarli in un secondo momento. Oppure ci si è infilati dentro un BLOB, ancora più stupido.

Non utilizzare un db relazionale per dati non relazionali, lo strumento non si adatta. Prendi in considerazione qualcosa come MongoDB o CouchDB per questo. Archivi di dati non relazionali senza schema. Conservalo come JSON se sta arrivando in qualche modo a un client, usa XML per il lato server.

CouchDB ti offre il controllo delle versioni pronto all'uso.

Non archiviare i dati di configurazione in un database a meno che tu non abbia un'ottima ragione per farlo. Se hai un motivo molto valido e sei assolutamente certo che lo farai, probabilmente dovresti memorizzarlo in un formato di serializzazione dei dati come JSON o YAML (non XML, a meno che tu non abbia effettivamente bisogno di un linguaggio di markup per configurare la tua app - - fidati di me, non lo fai) come una stringa. Quindi puoi semplicemente leggere la stringa e utilizzare gli strumenti in qualsiasi lingua in cui lavori per leggerla e modificarla. Memorizza le stringhe con i timestamp e hai un semplice schema di controllo delle versioni con la possibilità di archiviare i dati gerarchici in un sistema molto semplice. Anche se non hai bisogno di dati di configurazione gerarchici, almeno ora se ne hai bisogno in futuro non dovrai cambiare la tua interfaccia di configurazione per ottenerli. Ovviamente perdi la capacità di fare query relazionali sui tuoi dati di configurazione, ma se stai memorizzando molti dati di configurazione, probabilmente stai facendo qualcosa di molto sbagliato.

Le aziende tendono ad archiviare molti dati di configurazione per i loro sistemi in un database, non sono sicuro del perché, non credo che molte decisioni vengano prese in queste decisioni. Non vedo questo genere di cose fatto troppo spesso nel mondo OSS. Anche i programmi OSS di grandi dimensioni che richiedono molta configurazione come Apache non necessitano di una connessione a un database contenente una tabella apache_config per funzionare. Avere una grande quantità di configurazione da gestire nelle tue app è un cattivo odore di codice, l'archiviazione di quei dati in un database causa solo più problemi (come illustra questo thread).

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