Memorizzazione di una tabella di consultazione molleggiata

-1

Sfondo

Il prodotto su cui sto lavorando ha una lunga tabella di ricerca molto . la tabella contiene dati statici e non può essere generata automaticamente. ci sono circa 500 righe e 10 colonne. le colonne hanno per lo più interi e stringhe. per complicare le cose, ci sono in realtà due di queste tabelle. ogni riga in table-1 esegue il mapping a zero o più righe nella tabella-2.

usiamo un database SQLite con due tabelle. il programma di installazione del prodotto posiziona il file SQLite nella directory di installazione. l'applicazione è scritta in dot-net e usiamo ADO per caricare i dati una volta all'avvio.

ora,

  1. la tabella di ricerca cresce. in ogni uscita al mese, aggiungiamo circa 10 nuove voci
  2. le voci esistenti vengono modificate. ogni versione perfezioniamo le voci esistenti.

Il problema

un gruppo di (10) sviluppatori lavora sulla tabella di ricerca. Il codice va nel SVN, ma il piccolo diavolo lo SQLite no. questo impedisce a molti sviluppatori di lavorarci sopra. eseguiamo regolarmente i backup del file, ma non è possibile eseguire il controllo delle versioni corretto. non sappiamo mai chi ha fatto il cambiamento decisivo. la cosa peggiore è che non sappiamo se c'è qualche cambiamento. diff'ing database è noioso se non impossibile.

ci si aspetta che le tabelle crescano abbastanza grandi negli anni a venire e avremmo bisogno che gli sviluppatori lavorino in parallelo su di esso. i dati sono critici per l'azienda. dobbiamo essere in grado di controllare le modifiche apportate ad esso.

Domanda

Quale sarebbe la soluzione per i problemi sopra descritti? l'idea era di trasformare l'intera cosa in XML e trattarla come un semplice file sorgente. in questo modo SVN può eseguire il controllo delle versioni e possiamo lavorare in parallelo. ma i dati mostrano un comportamento relazionale. con XML perdiamo i vincoli univoci ed estranei. inoltre non possiamo interrogarlo con facilità sql.

qualsiasi aiuto qui sarà apprezzato.

    
posta inquisitive 03.06.2014 - 08:30
fonte

1 risposta

1

Idealmente, si sviluppa un piccolo programma per eseguire la modifica, in modo da poter modificare il file (e magari persino eseguire l'aggiornamento e il commit svn come parte del programma). Potrebbe essere più lavoro, quindi hai tempo. Non ho mai avuto quella volta.

Invece, ho avuto persone che modificano nel database e hanno creato un piccolo script che hanno eseguito (forse come trigger di svn, forse no, non ho mai provato) che ha caricato / scaricato il database in uno o più file. I file diventano quindi il "master". Eventuali modifiche al database vengono perse a meno che non vengano eseguite operazioni di dumping e commit. È un leggero cambiamento culturale, ma nella mia esperienza, dopo che le persone hanno perso il lavoro una o due volte, l'hanno capito. Idealmente, ognuno ha la propria copia del database costruita dai file che ha estratto e non si ha più un database di sviluppo (si ha un database notturno di build, ovviamente, ecc.), Quindi non devi preoccuparti su come raccogliere altre modifiche quando si esegue il commit e svn gestisce il parallelismo. Assicurati di scaricare il tuo database in un ordine ragionevole di righe in modo da poter vedere facilmente cosa è stato cambiato.

Buona fortuna. Vorrei che ci fosse una risposta migliore (c'è, ovviamente, ma costa soldi).

    
risposta data 03.06.2014 - 09:30
fonte

Leggi altre domande sui tag