[QUOTE]Originariamente inviato da brutusin
A questo punto se non ho capito male voi dite che è il caso di creare una QUARTA tabella che mi metta in relazione l'oggetto presente in TBANAGRAFICA con TBSOTTOSERVIZI
quindi avrò TBRELAZIONI cosi strutturata
id - idAnagrafica - idSottoServizi [QUOTE]
Non e' proprio cosi. Ti ho consigliato qualcosa di leggermente diverso. Non conoscendo cosa devi fare, dal poco che hai detto
records che hanno la possibilità di avere una marea di opzioni
ti ho consigliato di mettere i servizi (opzioni) in una tabella specifica e creare una terza tabella di relazione con solo 2 campi istruttura e idservizio. E' cosi' che si fanno le relazioni molti a molti. L'esempio di db che hai postato e' un po' diverso. La domanda che dovresti porti e': una struttura puo' avere molte categorie oppure solo 1? Nel caso solo una basta mettere un campo idcategoria nella tabella strutture altrimenti, se una categoria puo' essere in relazione con molte strutture e una struttura puo' essere in relazione con molte categorie devi usare una terza tabella con solo 2 campi (e non 3 come hai messo tu) idstruttura e idcategoria.
Aggiungo un altro consiglio e cioe' di dare un nome migliore alle chiavi primarie delle tabelle. Es
TBANAGRAFICA (perche' poi TB... ?) avra' come chiave primaria IDAnagrafica . In questa maniera farai meno confusione nelle relazioni.
però se devo mettermi a fare una query che mi estragga tutti i records che hanno un determinato sottoservizio è un disastro o sbaglio ?
E' necessario conoscere come usare sql per mettere in relazione le tabelle dopo di che non e' un disastro anzi... e' un piacere
se uno mi spunta 15 checkBox con i relativi servizi è un casino
qui entra in gioco l'interfaccia utente e potrebbe non essere una passeggiata costruirsi una query sql in base alle opzioni selezionate. Cmq si puo' vedere come fare...