STRUTTURARE DATABASE: join multiple o record completi?

[sgabello]

Ciao a tutti!
Mi piacerebbe avere una vostra opinione:
Devo creare un database di oggetti che hanno sempre le stesse caratteristiche ma valori descrittivi differenti.
ES:
oggetto colore forma
-----------------------------
1 rosso sfera
2 bianco cubo
3 verde piramide

Dove le caratteristiche sono numerose.
Un modo di fare sarebe quello di creare delle tabelle per ogni caratteristica (colore, forma, etc) e relazionarle alla tabella degli oggetti tramite degli ID. Questa soluzione pero' richiederebbe delle query con join multiple che immagino siano devastanti per il database (oltretutto difficili da scrivere).

Secondo voi avrebbe senso NON relazionarle alla tabella degli oggetti e memorizzare direttamente i valori nei record? Mantenendo cmq le singole tabelle delle caratteristiche, visto che il backend di compilazione deve essere "guidato"?

Non so cosa fare...

[optime]

ci sono diverse considerazioni da fare. la prima è questa: quante tipologie hai? ad esempio, il colore può essere solo bianco o nero... ovviamente fare una tabella di colori non ha senso. se invece hai 100 colori (o anche solo 10...) la tabella di riferimento ha un senso.

è ovvio che usando le relazioni le query diventino un po' più complesse, ma è solo questione di prenderci la mano.

un altro vantaggio è a livello di occupazione di spazio. "2" occupa meno spazio di "verdino pisello pallido" . Se poi la cosa la moltiplichi per n-mila records...

senza pensare poi alla fatica di inserire i dati e alla possibilità di errore. "verdino pisello pallido" e "verdino piselo pallido" son due cose diverse...

comunque, ripeto, dipende. in generale però propendo per le tabelle relazionate.

[sgabello]

Ecco... vedi... gli aspetti fondamentali sono esattamente quelli che hai esposto.
le tipologie per ogni caratteristica possono essere poche o tante... il progetto prevede proprio che siano "aggiornabili" e gestibili...
Già solo qui, le tabelle "esterne" diventano un obbligo... per usarle nel backend per generare dinamicamente i contenuti dei dropdown menu.

Di fatto quindi il problema delle immissioni errate, o dupilicate non sussiste... perchè cmq nella tabella principale memorizzerei solo i valori effettivi dei campi delle tabelle delle caratteristiche. Non sarebbe una immissione libera.


Il dubbio è sul relazionarle. Ho paura che una semplice select di visualizzazione che pero' contiene magari 10 o 20 join, sia davvero eccessiva in termini di prestazioni.

[optime]

perché 20 join? come sono fatte le tue tabelle?

[Gioba66]

non importa fare 20 tabelle. ne può bastare anche 3
quella delle caratteristiche può essere una sola, se usi un campo per la categoria

idcaratteristica (contatore)
idcategoria (categoria della caratteristica)
descrizione

quindi hai

1 1 verde
2 1 rosso
3 1 giallo
4 2 sfera
5 2 cubo
6 2 piramide
ecc.....

[optime]

gioba, poi devi fare una tabella di categorie. la considero una complicazione.

[sgabello]

E invece io la trovo un'ottima soluzione... invece che farmi 20 tabelle, una per categoria, usando il metodo postato da giobba complico un po' la struttura "logica" del database, ma la rendo molto più flessibile la struttura "fisica".

Per esempio se un giorno volessi aggiungere una nuova categoria, non sarei costretto ad intervenire sul database per aggiungere una nuova tabella!

Devo studiare un po' la cosa... perchè cmq le caratteristiche devono risultare omogenee... pero' si puo' fare!!!




Rimane aperta la questione sulla pesantezza delle join... ah... tra l'altro... come utilizzo le join nella query di selezione usando il tuo metodo giobba? Ci sto' pensando, ma non mi viene molto facilmente...

[optime]

secondo me le mani nel db ce le devi mettere comunque. oggi hai forma e colore. domani vuoi anche odore. ok per la tabella delle categorie, ma nella tabella principale a quale campo lo colleghi?

[sgabello]

Si... ok... su questo hai ragione...

Cmq... non voglio divagare troppo dal mio problema principale.

Dai dai

[santino83]

io opto per le 4 tabelle:

tab 1: tutti i colori

tab 2: elenco oggetti (volendo il riferimento al colore lo si mette qui, altrimenti si potrebbe fare una ulteriore tabella)

tab 3: elenco caratteristiche

tab 4: tabella collegamento oggetto - caratteristiche