Tabella DB con colonna per ogni tipo di dati

1

Ho bisogno di progettare un DB per la memorizzazione dei dati valore-chiave. L'elenco dei nomi di chiavi non è fisso e dovrebbe espandersi in un secondo momento. Non voglio creare una tabella con una colonna per ogni chiave, perché avrò bisogno di aggiungere colonne frequentemente e potrebbe diventare troppo grande, e ho capito che il design Entity-Attribute-Value non è efficiente. Ho pensato al seguente tipo di design del tavolo, e sto chiedendo se ha senso e chiunque può venire con qualche inconveniente legato all'efficienza, alle dimensioni della tabella o qualsiasi altro problema -

Ogni colonna nella tabella è di un tipo di dati diverso; le colonne irrilevanti per una chiave sono NULL:

ID |DataType |KeyName |ValInt |ValSmallInt|ValBool |ValStr  |ValText  |ValDate
-------------------------------------------------------------------------------
1  |1 (int)  |Width   |100    |NULL       |NULL    | NULL   | NULL    | NULL
2  |1 (int)  |Height  |200    |NULL       |NULL    | NULL   | NULL    | NULL
3  |2 (bool) |IsActive|NULL   |NULL       |false   | NULL   | NULL    | NULL
4  |3 (text) |URL     |NULL   |NULL       |NULL    | NULL   | w.com   | NULL
5  |1 (int)  |Size    |4      |NULL       |NULL    | NULL   | NULL    | NULL
6  |4 (date) |Created |NULL   |NULL       |NULL    | NULL   | NULL    | 2/2/2012

Il numero di colonne sarà il numero di tutti i tipi di dati (circa 30?).

La colonna DataType è un flag di tipo int che viene utilizzato per il chiamante: indica da quale colonna deve essere preso il valore.

Ogni riga è in realtà una proprietà di alcuni oggetti in un'altra tabella. Un insieme di righe crea un insieme di proprietà per quell'oggetto e in genere un SELECT otterrà l'intero set.

    
posta Max 05.07.2013 - 10:21
fonte

1 risposta

2

Hai ragione che rappresentare chiavi diverse come colonne in una tabella è una cattiva idea. La cosa giusta da fare è rappresentarli come righe differenti.

Questo lascia il problema di memorizzare i valori di diversi tipi in modo uniforme. Le alternative sono

(a) memorizzandoli in diverse tabelle, al costo di dover eseguire query diverse per cercare valori di tipi diversi e dover usare JOIN per recuperare i valori tutti . A seconda di quale sarà il tuo modello di utilizzo, questa potrebbe essere una buona idea. Ad esempio, se normalmente si cercano valori individuali piuttosto che l'intero set e se il chiamante sa che tipo rappresenta ogni chiave, allora questa è la soluzione migliore.

(b) memorizzandoli tutti nella stessa tabella, al costo di dover utilizzare il minimo comune denominatore per il tipo della colonna del valore. Ciò significa dover eseguire il cast o trasformare il valore ogni volta che lo si recupera e probabilmente anche memorizzare un flag di tipo in ogni record. Questa sarebbe un'idea orribile in un linguaggio di programmazione orientato agli oggetti, perché hanno opzioni migliori per le collezioni polimorfiche, ma può essere la soluzione migliore per uno schema di database se si desidera un recupero efficiente, o il chiamante non conosce necessariamente il tipo di ogni chiave.

Si noti che la soluzione richiederebbe più colonne per gli stessi dati e richiederebbe anche al chiamante di sapere quale tipo recuperare (o di controllare tutti i campi alternativi per scoprire quale non è NULL ). Quindi andrei con (a) o (b), invece, a seconda di quale sarà il tuo modello di utilizzo tipico.

    
risposta data 05.07.2013 - 10:41
fonte

Leggi altre domande sui tag