Devo ricostruire il mio database di sola lettura ogni volta che avvio il mio server?

Forse non è una soluzione fattibile per te. Cosa stiamo facendo in alcuni casi: utilizziamo le funzionalità di dump dei database inmemory.

• Durante il processo di costruzione stiamo creando un database inmemory (hsqldb ...)
• esegue il dump del database in un file
• aggiungilo al pacchetto di implementazione
• Dopo aver avviato la webapp, carichiamo il file scaricato e utilizzare il database.

Quindi

1. non distribuire il codice "come ottengo il database"
2. costruisci il tuo database durante la compilazione automatica e non durante l'avvio della tua app, che può durare un sacco di tempo.

Se è tutto di sola lettura, perché hai bisogno di un database?

Ma esiste una ragione per cui CREATE TEMP TABLE esiste, non aver paura di usarlo (ma ricaricarlo ogni volta che il processo si avvia è probabile che sia più costoso che lasciarlo su disco).

Dipende da cosa vuoi fare con quei dati.

Se hai bisogno di cercare quei dati e hai bisogno solo di piccole parti di esso alla volta, allora tenerne tutto nel database è una buona idea. Il database implementa già algoritmi di ricerca rapida e cache di memoria per i dati. Il database è anche una struttura naturale per i dati se i dati stessi hanno molte relazioni. Infine, il database fornisce anche un modo per caricare i dati nel sistema senza dover ricompilare \ ridistribuire il sistema.

Tuttavia, se hai bisogno di tutti i dati per quasi tutti i calcoli, i dati non cambiano, l'applicazione è critica dal punto di vista delle prestazioni (e non esegue ricerche) e non avrai mai bisogno di cercare o cercare una fetta dei dati, quindi è possibile inserire i dati nel codice dell'applicazione.

In termini di impostazione e spostamento di un database da un computer a un altro, in genere si tratta del processo di installazione / distribuzione. Se si mantengono tutte le impostazioni di configurazione (nome server, id server, nome utente, password, ecc.) In un file di impostazioni modificabili, è possibile spostare più facilmente il software da una macchina all'altra. Se la licenza del database lo consente, è possibile installare il software del database insieme allo schema e ai dati come parte del processo di installazione.

Se il tuo database è veramente letto solo allora non hai motivo di ricostruirlo, perché non cambia mai, quindi non hai motivo di ricostruirlo ogni volta.

Se ciò che ti preoccupa è che potresti avere il tuo database fuori sincrono con la versione del codice dell'applicazione, allora un modo per ovviare a questo è usare un sistema di database basato su file come SQLite o come un gruppo di JSON / XML in una directory. Basta controllare il file .db di SQLite insieme al codice dell'applicazione.

L'hard coding dei dati nell'applicazione è considerato una cattiva pratica per tutto tranne che per i dati più banali.

Se decidi di fare questo codice i "dati" in un modulo separato!

Se comprendo i tuoi requisiti, desideri distribuire i dati con l'applicazione in un unico pacchetto coesivo. Poi -

Codifica i tuoi dati in un singolo file JSON / XML che puoi comprimere con l'applicazione e caricarlo in un database stype di memcache quando l'applicazione è initalizzata. -o- Crea un database SQLite. Un database SQLite è costituito da un singolo file che può essere distribuito insieme alla tua applicazione. La maggior parte delle distribuzioni php / python include sqlite built in.

Nello sviluppo web, il codice dell'app e i dati del database sono mantenuti separati. Non inserire mai il codice nel database, non ha alcun senso. Per rispondere alla tua domanda originale:

No, non dovresti ricostruire il tuo database di sola lettura ogni volta. Dovresti creare il database una volta e aggiungere dati nel tempo.

Una cosa che non aveva senso per me è perché dovresti riavviare il tuo server spesso? I server sono progettati per rimanere costantemente online, quindi qualsiasi riavvio dovrebbe essere raro.