Newsgroup: it.comp.software.database
Titolo: Relazioni da 1 a molti, record vincolati e amenita' varie.

Premetto che sono un niubbo (almeno da queste parti), ma ho una discreta
conoscenza di ASP e del linguaggio SQL (quindi eventuali risposte infarcite
di tecnicismi non dovrebbero causarmi problemi di sorta), inoltre: tutto
quel che scrivo potrebbe far credere che io stia facendo un lavoro e stia
cercando di farmi risolvere il problema. Leggendo quanto segue si dovrebbe
capire che non e' cosi', ma per sicurezza... meglio dirlo prima. Mi sono
semplicemente posto un problema, ho pensato ad una soluzione e propongo
l'uno e l'altra.
Alura:
Immaginiamo un DB combinato in cotal guisa:
Un gruppo di tabelle definisce delle persone, un'altro un insieme di
servizi.
La prima tabella delle persone la definiamo come "tblAnagrafica" e contiene,
oltre ad un campo rowGuid (unique identifier) ci sono i campi canonici
(nome, cognome, indirizzo, numero di scarpe ecc ecc ecc) e il campo
"categoria", vincolato alla tabella "tblCategoria" che ha due campi:
ID(contatore), Descrizione [varchar(255), duplicati non ammessi]: i valori
che il campo tblAnagrafica.categoria puo' contenere sono quelli ritornati da
"SELECT descrizione FROM tblCategoria". E fin qui nulla di insolito.
Diciamo pure che esiste un'altro gruppo di tabelle tra cui
tblServizi (e qui cominciano i dolori) e che ha altri campi:
ID (contatore),
IDPersona(tblAnagrafica.rowGuid),IDServizio(tblDescrizioneServizio.Descrizio
neServizio), altri campi.
tblDescrizioneServizio
ID (contatore), DescrizioneServizio [varchar(255), duplicati non ammessi].
Alla fine, con un bel miscuglio di query, VBScript e HTML infilato dentro a
MS IIS5 e MS SQL server 7.0, mescolato e shakerato ben bene, riesco ad
ottenere una bella pagina HTML dove, ad una persona riesco ad associare
diverse informazioni, oltre al nome & cognome, anche i servizi che offre e
tutti i dati relativi a quei servizi, volendo posso creare anche un'altra
pagina HTML dove dal nome del servizio (o dal suo codice) posso risalire a
tutti quelli che lo forniscono.
Ecco.
Se devo andare a leggere una base di dati non ho assolutamente alcun
problema (a patto di avere il diritti giusti).
I problemi nascono quando devo andare a scrivere, pardon, alimentare una
base di dati. A parte la struttura di raccolta (che non e' il mio problema):
in che modo posso inserire un nuovo socio? E un nuovo servizio? E un socio
che non ha servizi?
Che problemi mi trovero' ad affrontare?
Posso semplicemente inserire dati in una tabella qualsiasi di questo DB?
Se inserisco un dato in una tabella con una relazione di "molti a uno" e
specifico "l'appartenenza" ad un record che non esiste, che succede?
Ho scelto la soluzione migliore? Mi sono posto una domanda "del cactus"
(come si dice dalle mie parti)? O piu' semplicemente ho scoperto un nuovo
giacimento di "diidruro di ossigeno" ad elevata temperatura?
Grazie per l'attenzione
Nettuno

Se ho capito bene la struttura del tuo DB, credo che dovrai inserire per
prima cosa i record delle descrizioni (ad esempio  tblDescrizioneServizio).
Poi potrai inserire gli elementi della tabella Servizio e solo infine
potrati aggiungere record alla tabella Persona.
Devi avere già gli ID delle descrizioni per utilizzarli nella tabella dei
servizi, stessa cosa vale per gli ID dei servizi : devono esistere per poter
essere utilizzati nella tabella delle persone!!
Devi ragionare come se avessi una o più catene di tabelle e devi partire ad
inserire i dati da quelle più esterne, cioè da quelle che non hanno nessuna
chiave importata dalle altre.
Non credo che questa soluzione sia complicata, devi solo essere molto
attento all'ordine con cui inserisci i record nelle tabelle.
Cosa più complicata è utilizzare gli identificatori universali (GUID) per
collegare i record relativi a tabelle diverse....ma questa è un'altra
storia!!!
Spero di esserti stata utile
     Ciao
                  Vale

 storia!!!
Fortunatamente no, in SQL 7 c'e' una cosa tanto simpatica che si chiama
uniqueIDentifier:
se pure ci si mettesse a generare un identificatore al secondo per cento
anni (sono tantini eh?) forse puo' capitare un doppione. Forse.
Un controllino sugli identificatori gia' usati toglie questo problema.
Quanto al resto: ho capito che devo riempire una parete di diagrammi di
flusso (il database che hai visto qui pubblicato era una versione MOLTO
semplificata, grossomodo di un ordine di grandezza (sob) ;___;  ) dove possa
vedere tabelle, stored procedure e compagnia bella (c'e' anche una parte che
riguarda il web).
Ricapitolando la regola base e':
Prima di inserire effettuare l'analisi formale dei dati.
Ohime'.
Nettuno