Principale utente con più risposte
Tabella di dettaglio per gestire un numero variabile di proprietà

Domanda
-
Salve a tutti,
nella mia webapplication faccio uso di SQL Server 2008 R2.
Devo creare una struttura dati che sia dinamica, in pratica i campi che devo utilizzare variano in base a determinate condizioni.
Per questo pensavo di creare una tabella di dettaglio che contiene la classica struttura Chiave - Valore.
Quindi ad esempio se il record è riferito ad una persona, nella tabella di dettaglio avrò i record con la coppia chiave - valore:
- Nome: Pippo
- Sesso: M
- Data di nascita: 10/08/1980
- Nazionalità: Italiana
Se si tratta di una macchina, avrò:
- Marca: Fiat
- Modello: Panda
- Colore: Rosso
Ai fini delle prestazioni, ricerca dati o altro, è consigliabile questo tipo di struttura?
Oppure è meglio creare una tabella diversa per ogni tipo di entità? Ad esempio Tabella_Persone e Tabella_Macchine?
Diego Riccardi
Risposte
-
Ciao
Il sistema che hai pensato presta il fianco a diverse problematiche.
Non puoi sfruttare i controlli di tipo offerti da SQL. Quale tipo di dato userai per il value? varchar?
Nell'esempio che hai inserito hai indicato una "Data di nascita", e il tipo di dato varchar non ti permette di fare controlli, cosa che dovrai demandare all'applicativo.Non puoi definire i nomi dei campi. In un caso potresti scrivere la chiave "datanascita" e in un altro caso "datadinascita".
Potresti avere problemi nella gestione dei vincoli di integrità referenziale.
Diventa inoltre difficoltoso gestire la costruzione del risultato in una unica riga.
A mio avviso dovresti chiederti intanto con quante entità avrai a che fare e con che frequenza ne avrai di nuove. Cercherei inoltre di analizzare le entità per capire se sono relazionate tra di loro da un rapporto di ereditarietà.
Soluzioni alternative potrebbero essere la creazione di tipi e sottotipi.
Oppure potresti realizzare una tabella unica con tutti gli attributi delle entità (se il loro numero è limitato) e valorizzare solamente quelli che ti interessano.
Oppure, altra soluzione ancora, potresti salvare i dati comuni alle entità in una singola tabella e poi aggiungere un campo BLOB dove memorizzare gli attributi aggiuntivi in formato XML o JSON.
Daniele
- Proposto come risposta Edoardo BenussiMVP, Moderator martedì 3 febbraio 2015 14:06
- Contrassegnato come risposta Diego Riccardi martedì 3 febbraio 2015 17:05
Tutte le risposte
-
Ciao Diego, secondo me si. A entità diverse devono corrispondere tabelle diverse.
mario formosa
- Proposto come risposta Edoardo BenussiMVP, Moderator martedì 3 febbraio 2015 14:06
-
Ciao
Il sistema che hai pensato presta il fianco a diverse problematiche.
Non puoi sfruttare i controlli di tipo offerti da SQL. Quale tipo di dato userai per il value? varchar?
Nell'esempio che hai inserito hai indicato una "Data di nascita", e il tipo di dato varchar non ti permette di fare controlli, cosa che dovrai demandare all'applicativo.Non puoi definire i nomi dei campi. In un caso potresti scrivere la chiave "datanascita" e in un altro caso "datadinascita".
Potresti avere problemi nella gestione dei vincoli di integrità referenziale.
Diventa inoltre difficoltoso gestire la costruzione del risultato in una unica riga.
A mio avviso dovresti chiederti intanto con quante entità avrai a che fare e con che frequenza ne avrai di nuove. Cercherei inoltre di analizzare le entità per capire se sono relazionate tra di loro da un rapporto di ereditarietà.
Soluzioni alternative potrebbero essere la creazione di tipi e sottotipi.
Oppure potresti realizzare una tabella unica con tutti gli attributi delle entità (se il loro numero è limitato) e valorizzare solamente quelli che ti interessano.
Oppure, altra soluzione ancora, potresti salvare i dati comuni alle entità in una singola tabella e poi aggiungere un campo BLOB dove memorizzare gli attributi aggiuntivi in formato XML o JSON.
Daniele
- Proposto come risposta Edoardo BenussiMVP, Moderator martedì 3 febbraio 2015 14:06
- Contrassegnato come risposta Diego Riccardi martedì 3 febbraio 2015 17:05
-
ai fini delle prestazioni è certamente avere tabelle diverse in base alla tipologia di record.
Edoardo Benussi
Microsoft MVP - Directory Services
edo[at]mvps[dot]org- Proposto come risposta Edoardo BenussiMVP, Moderator martedì 3 febbraio 2015 14:06
-
Grazie per la risposta.
infatti usare dati tipizzazione era proprio quello a cui stavo pensando e che poteva essere un problema il fatto di dover usare un campo di tipi stringa per tutte le proprietà.
Poi sicuramente dovrò fare delle operazioni matematiche su alcuni di questi campi, quindi la soluzione con una tabella per ogni entità è sicuramente la cosa migliore!
Diego Riccardi