Il modo migliore per memorizzare i dati delle impostazioni del sito Web in una tabella di database?

Question

Sto lavorando su un mercato e mi chiedevo qual è il modo migliore di gestire le impostazioni del sito web come titolo, url, se https, email di contatto, versione, ecc.

Sto provando a strutturare la tabella in modo è facile da aggiornare e in grado di avere sempre più impostazioni aggiunte per il recupero.

Ho sviluppato 2 strutture, o la tengono in una riga, con i nomi delle colonne come nome dell'impostazione e il valore della colonna riga come valore di impostazione. e fa solo eco al nome della colonna del valore della prima riga con un mysql_fetch_assoc.

Stavo anche pensando di avere una nuova riga di incremento automatico per ogni impostazione. E trasformandolo in una matrice da recuperare dal database per assegnare un nome di colonna per la colonna di recupero del nome dell'impostazione.

Quale sarebbe il modo di gestirlo in modo efficiente. grazie.

Answer 1

I due modi funziona correttamente. Direi che se vuoi amministrare queste impostazioni in un pannello di amministrazione, l'impostazione per colonna è migliore, perché puoi aggiungere nuove impostazioni in tempo reale con una semplice query INSERT dall'amministratore. Che è meglio (più sicuro) di una query ALTER TABLE.

Answer 2

Una riga per ogni impostazione di opzione distinta, utilizzando coppie nome/valore una per riga, è probabilmente il modo migliore per andare. È più flessibile di molte colonne; se aggiungi un'impostazione di opzione, non dovrai eseguire alcun tipo di operazione ALTER TABLE.

La tabella wp_options di WordPress funziona in questo modo. Vedere qui. http://codex.wordpress.org/Options_API

Se si dispone di un'opzione "composta", è possibile serialize un array php per archiviarlo in una singola riga della tabella.

Answer 3

Dipende dalla tecnologia che si sta utilizzando. Ad esempio in un progetto Symfony di PHP, le impostazioni sono principalmente memorizzate in file flat (Json, xml ...).

Ho lavorato su molte grandi applicazioni web per i clienti. La tabella chiave/valore viene comunemente utilizzata per memorizzare le impostazioni semplici. Se è necessario memorizzare più di un valore, è necessario serializzarli, quindi è un po 'complicato.

Ricordare di immettere dati sensibili come password (Sha256 + sale).

Il modo migliore è creare due tabelle. Una tabella per memorizzare le impostazioni come chiave/valore:

CREATE TABLE Settings (
    Id INT NOT NULL PRIMARY KEY, 
    Key NOT NULL NVARCHAR, 
    Value NULL NVARCHAR 
    EnvId INT NOT NULL 
); 

allora avete bisogno di un tavolo ambiente.

Non dimenticare il vincolo di chiave esterna.

Inoltre, è necessario creare queste tabelle in uno schema separato. Sarai in grado di applicare una politica di sicurezza filtrando l'accesso.

Quindi è possibile lavorare con molti ambienti (dev, test, produzione, ....) è sufficiente attivare un ambiente. Ad esempio, è possibile configurare di non inviare e-mail nello sviluppo env, ma inviarle in ambiente di produzione.

Così si esegue un join per ottenere le impostazioni per un ambiente specificato. Puoi aggiungere un booleano per passare facilmente da un ambiente all'altro.

Se si utilizza un file (non ha bisogno di connessione db) si può ottenere qualcosa di simile (JSON):

Env: 
    Dev: 
     Email: ~ 
    Prod: 
     Email: contact@superwebsite.com 

Answer 4

Prima di tutto vorrei considere una cosa, un file di configurazione .. .

Allora dovresti chiederti che cosa avete bisogno per il vostro progetto ...

Prima di tutto vorrei considere file di configurazione del database vs:

Il grande vantaggio delle opzioni di database su un file di configurazione è la scalabilità, se ci sono molte applicazioni/siti che requiering quelle configurazioni quindi andare per il database in quanto eviterebbe di copiare più volte lo stesso file di configurazione con tutto il problema di versioning e modifica del file su tutti quei "siti" diversi

In caso contrario, vorrei attenermi al file di configurazione poiché l'accesso è più veloce per un'applicazione e il file potrebbe essere ancora disponibile in caso di interruzione del server SQL nel qual caso qualche configurazione potrebbe essere ancora rilevante, il il file di configurazione potrebbe anche includere il software di controllo delle versioni. Per alcuni motivi di sicurezza, immagina che il tuo DB sia condiviso da molti software ...

Quindi se ti attieni al database ti consiglierei una riga una etichetta una config, quindi è più facile gestire i record che la struttura della tabella, specialmente nel tempo e nell'evoluzione del tuo software. Se altri sviluppatori si uniscono al tuo progetto, la tua struttura di tabelle può diventare rapidamente un grande casino:]

L'argomento finale è la sicurezza ... una buona pratica è impostare l'utente "DB" forma un software per un utente che non ha i diritti di modifica della struttura DB, solo il diritto di accesso/moidify cancella i record;)