Che cos'è un design efficiente per memorizzare le variabili per diverse linee di prodotti nel database ER?

Naviga le tue risposte
3

Questa domanda riguarda il refactoring della progettazione del database esistente.

Il mio flusso di dati è

  1. L'utente genera alcuni dati per le linee di prodotto A, B, C
  2. I dati vengono salvati nel database una volta
  3. I dati vengono in seguito recuperati più volte

Il design attuale ha 3 tabelle: data_a , data_b , data_c , dove ogni tabella condivide alcune colonne identiche (nel nome) e alcune che sono univoche per quella linea di prodotti.

Ad esempio, le colonne con lo stesso nome in ogni tabella sono weight , unit_system e poche altre. Le colonne con nomi diversi hanno valori che rappresentano le quantità fisiche della particolare linea di prodotti. Quelli sono denominati utilizzando vari identificatori alfanumerici, come a , b5 , e2 e vi è un diverso insieme di essi per diverse linee di prodotti. Questi set possono condividere elementi, ad esempio b5 può trovarsi in più di una tabella, ma qualcosa come t1 può trovarsi in una tabella ma non nelle altre.

problema

Attualmente quando è necessario aggiungere un valore dire x9 alla linea di prodotti a, vorrei aggiornare lo schema del database per data_a per avere la colonna x9 . Rendo i valori di x9 come 0 per le righe di colonna esistenti e i nuovi record inizieranno a popolare con i valori effettivi di x9 . Quindi aggiorno il codice nelle posizioni pertinenti per inserire x9 nella tabella o recuperarlo dalla tabella.

Design esistente 

data_a(id, item_id, shared, different_a)
data_b(id, item_id, shared, different_b)
data_c(id, item_id, shared, different_c)

dovesharedcolonneèungruppodicolonneidenticoinognitabella,mentredifferentsonocolonnechesonodisgiunteinteoria,inquantorappresentano3diverselineediprodotto,mapotrebberoeffettivamentecondividereelementiconnomisimili,comealcuninomidivariabilisonoglistessiperdiverselineediprodotto.

Designproposto

Questoèdovestolottando.Perchénonvedounbuondesignpulitochesiaancheefficiente.Volevoeliminarelanecessitàdimodificareloschemadeldatabaseognivoltacheèstataaggiuntaunanuovavariabileaunalineadiprodotti.Ecredodipoterlofare,mavoglioanchecreareundesignefficiente,enonnevedouno.

Maquestoèilmiotentativo:

Mantienilachiaveprimaria,lachiaveesternaeinomidicolonnecondiviseinunasingolatabella:

data(id,item_id,shared)

Creaunasolatabellasoloperlevariabili(levariabilisonoquelletrovateindifferentset):

data_variables(id,item_id,data_id,variable,value)

Nonsonosicurochequestoprogettovarràlapena,perché...Veramentestomemorizzandopiùdati-tuttigliextradata_idotuttiivaloriextraitem_idperciascunnomedivariabile.Esistonoda15a30nomidivariabiliperciascunalineadiprodotti.Memorizzeròicampida15a30item_id(odata_id)nellanuovatabelladata_variablesdesign,dovenelvecchioprogettoc'erasolounitem_idvaloreperrigaditabella.

Domanda:

Esisteunaprogettazionepiùefficientechenonrichiedemodifichenellaprogettazionedelloschemaperogniaggiunta/eliminazione/modificadelnomedellavariabileinunalineadiprodotti?Potrebbeesseremeglioattenersialdesignesistentenonostanteilproblemadialterareloschemaquandoènecessarioaggiungerenuovevariabili?

UtilizzodiJSONpercampi"diversi" variabili 

one_data_table(id, item_id, product_line, shared, json_encoded_value_pairs);

Decisione di non utilizzare il modello EAV (Entity-attribute-value)

Nel mio caso le Entità cambiano molto raramente se non del tutto (nell'ordine degli anni), e anche gli attributi cambiano raramente, nell'ordine di mesi o più. Pertanto, rielaborare la progettazione del database per utilizzare EAV non è probabilmente adatto al mio caso.

A parte questo, sto ancora discutendo sul mio JSON Design.

    
posta Dennis 03.01.2017 - 18:14
fonte

1 risposta

3

Quindi capisco che non vuoi avere campi da data_* in item perché non sono proprio la stessa cosa. Che ne dici di qualcosa come questo schema qui sotto? È simile al tuo progetto originale, ma aggiunge una nuova tabella Common_data tra la tabella item e le tabelle data_* . 

Item
----
 - item_id
 - (other item-focused fields)

Common_Data
-----------
 - common_data_id
 - item_id - FK to item.item_id
 - shared_field_1
 - shared_field_2
 - (many fields that are already shared in data_a, data_b, and data_c)
 - data_type (can be "data a", "data b", "data c")

data_a
------
 - data_a_id
 - common_data_id  - FK to common_data.common_data_id
 - different_a

data_b
------
 - data_b_id
 - common_data_id  - FK to common_data.common_data_id
 - different_b

data_c
------
 - data_c_id
 - common_data_id  - FK to common_data.common_data_id
 - different_c

Pro:

  • semplifica i tuoi dati di shared , spostando il tutto in una tabella di dati comune.
  • simile al design esistente - forse alcuni dei tuoi codici esistenti possono essere salvati
  • i nuovi dati di shared devono essere aggiunti in un unico posto.
  • più semplice da implementare.

Contro:

  • potrebbe non essere abbastanza flessibile se pensi che presto avrai data_d , data_e , ecc ... e quindi rimuovi quelli più vecchi.
  • richiede ancora modifiche allo schema (e possibilmente al codice) quando vengono aggiunti nuovi dati _ * - campi specifici.

Eviterei di seguire la rotta EAV a meno che tu non abbia bisogno della flessibilità di farlo.

    
risposta data 03.01.2017 - 23:48
fonte

Leggi altre domande sui tag

Le migliori pratiche per rilevare la pirateria in Web-App (condivisione delle informazioni di accesso) La scrittura a mano OCR è più accurata se l'autore della calligrafia è indicato?