è meglio memorizzare la configurazione della piattaforma nel database o in un file?

Question

attualmente stiamo sviluppando un'app in cui utilizziamo la tabella di database per memorizzare le impostazioni della piattaforma, come la dimensione massima del file, il numero massimo di utenti, l'email di supporto, ecc.

significa che ogni volta che aggiungiamo un'impostazione di piattaforma dobbiamo aggiungi una colonna a questa tabella.

nei miei progetti precedenti sono abituato a memorizzare tali informazioni nel file.

qual è l'approccio migliore/più veloce?

ps, ​​sono quasi sicuro che qualcuno aveva già questa domanda, ma io non riesco a trovarlo

Answer 1

Dipende davvero dalla vostra applicazione.

memorizzazione delle impostazioni nel database ha diversi vantaggi:

1. Sicurezza - gli utenti possono facilmente modificare le impostazioni nel file o sovrascrivere il contenuto.
2. Per la distribuzione: le stesse impostazioni possono essere aggiornate e caricate su qualsiasi macchina sulla rete.

Svantaggi:

1. si basa sulla connessione al database
2. Overhead durante la lettura dal database

conservazione in vantaggi di file:

1. Veloce e facile da leggere e modificare .

Svantaggi:

1. problema di sicurezza di cui sopra.
2. Potrebbe richiedere la crittografia sui dati sensibili.
3. Il controllo delle versioni è difficile, poiché è necessario creare file separati per versioni diverse.

significa che ogni volta che aggiungiamo un ambiente piattaforma dobbiamo aggiungere una colonna di questa tabella - a seconda di cosa database in uso, ma è possibile memorizzare le impostazioni di interi come XML (SQL server permette questo) nella tabella, quindi non è necessario modificare lo schema della tabella ogni volta aggiungendo delle impostazioni; tutto ciò che devi fare è modificare l'XML, aggiungervi elementi o rimuoverlo.

ma alla fine, devi decidere tu stesso, non c'è di meglio o di peggio per tutti.

Answer 2

Perché una nuova colonna ogni volta? Perché non solo 2 colonne: NAME e VALUE.

Quello che facciamo è impostare i valori di default in un file, quindi sovrascrivere quei valori predefiniti nel database quando necessario, per distribuzione.

Inoltre, in termini di velocità, memorizziamo nella cache la configurazione (con la possibilità di attivare una ricarica). Non ha senso rileggere la configurazione ogni volta che ti serve una proprietà. Quindi in termini di velocità, non importa. Lo fai una volta.

Answer 3

Noi memorizzare le impostazioni di configurazione in una tabella di tipo chiave/valore, qualcosa di simile:

CREATE TABLE Configuration.GlobalSettings 
(
    SectionName VARCHAR(50), 
    SettingName VARCHAR(50), 
    SettingValue VARCHAR(1000), 
    SettingType TINYINT 
); 

Il SectionName & SettingName sono la chiave primaria, abbiamo appena li dividiamo per rendere più facile per interrogare ciò che è in un sezione, e per consentire il caricamento di singole sezioni in handler anziché caricare l'intero lotto in una volta. Lo SettingValue è una stringa, quindi lo SettingType è un discriminatore che indica come deve essere interpretato il valore di impostazione (ad esempio 1 = stringa, 2 = bool, 3 = decimale, ecc.).

Ciò significa che non è necessario modificare la struttura della tabella per le nuove impostazioni, basta aggiungerne una nuova nello script di distribuzione o ovunque siano state impostate.

Troviamo un modo migliore di fare config di un file perché significa che è possibile modificare a livello di programmazione i valori di configurazione tramite un'interfaccia di amministrazione quando necessario, che può imporre la logica attorno a ciò che può andare in ogni impostazione. Non è possibile farlo facilmente con un file (anche se, ovviamente, è possibile).

Answer 4

Posso dirvi che gestisco un'applicazione particolarmente ampia in numerosi siti che tenere configs in file locali è un dolore completo. Spesso le configurazioni vengono lette e memorizzate nella cache e non possono essere modificate durante il tempo di esecuzione, altre hanno sistemi di scalabilità orizzontale in cui le configurazioni devono essere ripetutamente modificate e rimbalzate.

La mia vita sarebbe più facile del 10% durante l'implementazione del panorama di sistema se i progettisti avessero semplicemente mantenuto le proprietà di sistema nel DB.

Answer 5

Per essere onesti, la risposta non è così chiara e dettagliata.

Le risposte di cui sopra non sembrano tenere conto delle applicazioni che devono essere implementate in diversi ambienti, ad esempio: dev, qa, staging, prod.

Inoltre non tengono conto dell'importanza della configurazione della versione, ovvero sapere chi ha cambiato cosa, dove e quando.

Tutti i framework moderni forniscono un modo per recuperare la configurazione corretta per ambienti specifici, in genere tramite la variabile di ambiente.

Ogni Environnment ha la propria configurazione, prendere in considerazione il modo in cui symfony espone i suoi file di configurazione:

your-project/ 
├─ app/ 
│ ├─ ... 
│ └─ config/ 
│  ├─ config.yml 
│  ├─ config_dev.yml 
│  ├─ config_prod.yml 
│  ├─ config_test.yml 
│  ├─ parameters.yml 
│  ├─ parameters.yml.dist 
│  ├─ routing.yml 
│  ├─ routing_dev.yml 
│  └─ security.yml 
├─ ... 

Per queste ragioni, ho sicuramente preferisco la configurazione nel file.

I miei 2 centesimi.

Answer 6

Penso che come tutti hanno detto, dipende dall'ambiente dell'applicazione e dai requisiti. Ma se dovessi scegliere una regola generale, direi ENTRAMBI. Per prima cosa, si crea una tabella del database per memorizzare tutte le configurazioni. Ciò è valido per due motivi: 1) Versioning: consente di tenere facilmente traccia delle configurazioni precedenti. 2) Gestione: è possibile creare un'interfaccia a cui gli utenti possono accedere per modificare le impostazioni.

In secondo luogo, si crea un file che dopo aver salvato e pubblicato il sito in produzione, salverà tutte le impostazioni in un file a cui sarà facilmente accessibile. Infatti, se si sta programmando in PHP per il web, quel file dovrebbe essere un file php con dati di array (coppie chiave-valore) che non necessitano di ulteriori manipolazioni. Con questo voglio dire, non c'è bisogno di convertire il tuo yaml o json in array se questo è l'output finale che devi avere.