Xml vs. Database per la configurazione dell'applicazione

Question

La configurazione della mia applicazione è molto gerarchica e si adatta perfettamente a un singolo XML. Presto (YAGNI, Yeh) parti di queste informazioni verranno utilizzate da altre applicazioni in remoto, che richiede un database.

Quindi, sono andato a progettare tabelle DB e mapparle alla gerarchia di classi della mia applicazione (usando EF). tuttavia è diventato un incubo di manutenzione.

Mi piacerebbe sentire dagli altri esperienza considerando questo problema, grazie.

Answer 1

Abbiamo avuto un'esperienza molto buona con l'archiviazione della configurazione in un database per applicazioni a esecuzione prolungata (come siti Web e servizi). Vantaggi:

• È possibile modificare la configurazione in remoto e in modo sicuro (user/password)
• E 'semplice per l'applicazione per prendere cambiamenti (select max(lmod) from config) automaticamente o da un segnale (ping una pagina web o creare un file vuoto da qualche parte)
• L'applicazione richiede solo una singola voce di configurazione per ambiente (dev, test, prod): il DB da utilizzare. Se si dispone di un server applicazioni, le applicazioni sono config libere per tutti gli ambienti.

Il problema principale è la modifica se si dispone di una struttura di configurazione gerarchica complessa con valori predefiniti, elenchi ed ereditarietà.Le nostre soluzioni:

• La tabella di configurazione ha queste righe: varchar Application (32), varchar chiave (512), valore varchar (4096)
• Un DB per ambiente (macchina sviluppatore locale, test di sviluppo, test di integrazione , produzione)
• La chiave è gerarchica (option.suboption .... nome)
• Defaults usano "l'opzione. .name" (ad esempio, "JDBC. .driver", dal momento che usiamo un solo tipo di database)
• Le liste sono memorizzate come stringhe, separate da newline.
• Le mappe sono come stringhe, "nome = valore \ n"
• Esiste un'implementazione che può leggere la configurazione da un file (per i test di unità). Mappare ogni gerarchia della chiave a un elemento (......)

Gli oggetti di configurazione nascondono questi dettagli, quindi l'applicazione funziona solo con gli oggetti.

Una classe speciale è responsabile della rilettura della configurazione in caso di modifica. Di solito, aggiorniamo la configurazione un po 'di tempo durante il giorno e un lavoro a tempo verrà ricaricato dopo ore. In questo modo, non abbiamo mai bisogno di sincronizzare i metodi di configurazione.

Backup e cronologia delle modifiche erano un problema, però. Lo abbiamo risolto utilizzando i file XML nel VCS che vengono poi "caricati" sul DB. In questo modo, abbiamo potuto verificare la configurazione di produzione prima di caricarla (usandola con una serie speciale di test unitari su una macchina per sviluppatori). Quando è stato attivato durante la notte, di solito ha funzionato subito e l'operatore responsabile dell'app avrebbe dovuto fare solo un po 'di test.

Answer 2

IMHO config dovrebbe vivere in file, i file funzionano bene per le persone e sono ok per i computer. I database funzionano bene per i big data, ma sono eccessivi per le cose umane. I due sono normalmente mutuamente esclusivi, e quando provi a combinarli ottieni qualcosa come il registro - uggh.

Perché non lasciare la configurazione in un file e creare un livello DAL e di servizio attorno ad esso in modo che le app possano utilizzarlo. Questo presuppone che tu possa ospitare su un server centrale, se non hai più copie del file in the wild.

Answer 3

L'utilizzo di un database (forse per memorizzare questo file di configurazione xml, se si desidera conservare il formato) presenta vantaggi: è possibile registrare/controllare le modifiche alla configurazione e anche eseguire il backup e il ripristino.

Fondamentalmente la tua domanda (il mio modo di vedere) mescola due cose,

1. Quale formato la configurazione dovrebbe essere in (XML, i file .ini, ecc)
2. dove dovrebbe essere conservato (piatte file su disco, colonna di tabella nel database)

È possibile memorizzare facilmente il file di configurazione xml in un database e fornire un'interfaccia per la modifica/visualizzazione delle informazioni.

Answer 4

I file di configurazione dovrebbero essere le cose più facili da gestire, quindi inseriscili nei file. In questo modo qualcuno può apportare modifiche lì anche con il blocco note (se necessario). Il database è davvero un overkill, a meno che tu non voglia che la tua configurazione risieda in qualche server globale e tutte le istanze per condividerlo.