Progettazione di database, tabelle parallele o campi aggiuntivi?

1

Gestisco un database per un centro di sequenziamento. Ci sono altri sviluppatori che prendono i dati da questo e che eseguono processi automatizzati e semi automatizzati dal database.

Stiamo discutendo di una modifica al database.

Al momento disponiamo di una libreria con una relazione uno a uno con multiplex_index, che può essere utilizzata per identificare la libreria. Ora vogliamo aggiungere un GBS_index opzionale a ciascuna libreria (un'altra relazione opzionale uno a uno). Quindi ogni libreria avrà un multiplex_index e opzionalmente un GBS_index.

Le colonne memorizzate sul nuovo GBS_index saranno le stesse di multiplex_index. Quindi abbiamo 2 opzioni per la memorizzazione dei dati GBS_index.

1) Memorizza i dati GBS_index nella tabella multiplex_index originale e identifica il campo "tipo".

2) Possiamo aggiungere una tabella parallela per GBS_index, che rispecchia la tabella multiplex_index.

Io preferisco l'opzione della seconda tabella parallela, poiché ritengo che sia meno probabile che si interrompa il codice esistente (gli script interrogano il database per un elenco di multiplex_indexes, in questo caso è necessario escludere l'indice GBL_indexes).

Concettualmente i due tipi di indici sono entrambi "indici multiplex", ma usati in modo leggermente diverso.

Esistono validi argomenti a favore o contro l'una o l'altra opzione?

Ok, una rapida spiegazione del sequenziamento del DNA può essere d'aiuto.

Il sequenziamento del DNA comporta il prelievo di DNA dalle cellule e la suddivisione in "letture" di circa 200 coppie di basi (ciascuna coppia di basi è come un DNA char A, T, G o C).

Carichiamo le librerie (DNA di un campione biologico preparato) su una macchina e le sequenziamo. I due tipi di indici di cui ho parlato sono un altro pezzo di DNA con una sequenza nota, che è collegato all'inizio del DNA della libreria prima che venga sequenziato. In questo modo, possiamo leggere il primo bit di sequenza che possiamo identificare da quale libreria sono stati letti (~ 200 caratteri). (Siamo generalmente interessati al numero di letture che corrispondono a una posizione su un genoma di riferimento).

Ora possiamo avere uno (multiplex) o due (multiplex + GBS) indici all'inizio del DNA della biblioteca (uno arriva dopo l'altro), che formano una combinazione unica per identificare la libreria.

Inizialmente due librerie con lo stesso multiplex_index non dovrebbero essere caricate insieme, poiché non è stato possibile identificarle dalla sequenza multiplex_index. Ora la combinazione dei due indici dovrebbe essere unica.

    
posta wobbily_col 20.09.2013 - 12:36
fonte

1 risposta

1

Tabella parallela:
È corretto che l'utilizzo di una nuova tabella "parallela" per GBS_index abbia meno probabilità di interrompere i processi esistenti. Anche se si potesse riutilizzare la vecchia tabella senza un campo di testo aggiuntivo, si cambierebbe la relazione da 1-1 a 1-molti. Questo sarebbe un cambiamento decisivo.

Lo svantaggio è che questo design non è guidato dai dati. Cosa succede se viene introdotto un terzo tipo di indice? 4 °, 5 ° .... 20 °? Non ho familiarità con il DNA, ma se i tipi possono scalare, richiederebbe un cambio di query ogni volta che viene introdotto un nuovo tipo. L'aggiunta di un tipo con una tabella parallela potrebbe non essere una modifica "di rottura", ma richiederebbe comunque una modifica ogni volta che viene introdotto un tipo. Scrivere query su 20+ tavoli sarebbe ingombrante.


Aggiungi un campo di testo aggiuntivo:
Questo design sarebbe un cambiamento decisivo. Stai cambiando la relazione da 1-1 a 1-molti. Ma se la relazione è davvero 1-molti, allora "dovrebbe" essere modellato in quel modo nel database.

Questo design è anche guidato dai dati. Ogni volta che viene introdotto un nuovo tipo, è sufficiente aggiungere dati alla tabella di ricerca "tipo". Non sono richieste modifiche alle query (eccetto per la modifica iniziale che stai facendo ora, ovviamente).


Conclusione:
Preferisco aggiungere il campo extra mentre modella la relazione 1-molti con una relazione 1-molti nel database. La tabella parallela emula un 1-many con relazioni multipe 1-1 e non è basata sui dati per i nuovi tipi in futuro.

Entrambi i disegni funzioneranno. Si tratta di quanto sia critico e politico un cambiamento di rottura. E se i tipi sono fissi su 2 o scala su N.

    
risposta data 20.09.2013 - 14:46
fonte

Leggi altre domande sui tag