Newsgroup: it.comp.software.database
Titolo: creazione database.....help

Ciao a tutti, mi aiutate???
devo creare un database per l'inserimento dei dati di un atleta di una 
societą:
Nome
Cognome
Data di Nascita
Sesso(m/f)
Comune di Nascita
Codice Comune di Nascita
Provincia di Nascita
Codice fiscale
Comitato di Appartenenza
Codice Comitato di appartenenza
Codice Atleta
Indirizzo Residenza
Comune Residenza
Numero Civico
CAP
Provincia di Residenza
Stato
Telefono
FAX
Email
Societą di Appartenenza
Anno Agonistico
Data Tesseramento
Tipo di Atleta(Agonistica, Master, Propaganda)
Vincolo(Provvisorio, Definitivo)
Tipo di Tesseramento(Tesseramento, Prestito)
Disciplina(Nuoto,Pallanuoto,Sincronizzato,Tuffi,Salvamento)
|--------------------------|
SOCIETA' DI APPARTENENZA(indicato sopra) presenta tutte le societą che sono
in un database chiamato "societa" che contiene:
Nome Societą
Comitato di appartenenza
Cod Comitato appartenenza
codice societą
Indirizzo
CAP
Comune
Prov
Tel
FAX
Email
Sito internet
Cod fiscale o partita iva
Responsabile
|--------------------------|
COMITATO(indicato sia in Atleta che in Societa) deve contentere:
Comitato
Cod Comitato
|------------------------------------------------------------------------------|
Qualcuno sa aiutarmi nella creazione di questo database?in modo che siano
tutte cose collegate tra loro??
Grazie 1000
Aspetto notizie
Ciao
Luca
-- 
________________________________
Luca Pandolfo
webmaster 
www.catanianuoto2000.it
webmaster 
www.conicatania.it
Redazione 
www.nuotosicilia.it
 

 |------------------------------------------------------------------------------|
Che informazioni contiene questa tabella?
In che modo sono legate all'atleta e alla societa'?
Es. atleta e societa' a cui appartiene possono appartenere a comitati 
diversi?
un atleta e una societa' appartengono sempre e solo a un comitato?
Ciao,
Paolo

 ha scritto nel messaggio 
news:46064d6c$0$4796$4faf...@reader4.news.tin.it...


 Basic
Usi Access o SQL Server?
Potresti usare un campo ad hoc, autoincrementante, per le PK. Renderebbe 
piu' facile la gestione lato applicativo.
Oppure usare un campo univoco (es. il codice fiscale o la P.IVA).
Ciao,
Paolo

 ha scritto nel messaggio 
news:46066023$0$4789$4faf...@reader4.news.tin.it...


 Cmq x VB, access!!!
Se fai qualche domanda precisa si puo' provare ad aiutarti, ma se 
rispondi cosi' non ti si puo' che consigliare un corso... :-)
Ciao,
Paolo

 Oppure usare un campo univoco (es. il codice fiscale o la P.IVA).
Quali problemi risolverebbe?
Non basta usare un linguaggio con gestione dinamica dei tipi? 

 Non basta usare un linguaggio con gestione dinamica dei tipi? 
Non mi e' chiaro: quale e' la relazione tra la gestione dei tipi del 
linguaggio usato e il tipo di campo che si usa come chiave?
Ciao,
Paolo

 linguaggio usato e il tipo di campo che si usa come chiave?
Pensavo che ti riferissi al fatto che un autoId e' di solito
integer e quindi piu' digeribile al compilatore/interprete, ma
vedo che devo attendere la risposta alla prima domanda :-)
bye

 soluzione originaria.
Attualmente la gestione della duplicazione delle chiavi e' implementata 
direttamente nel motore di qualsiasi DB.
Ciao.
	MAX

 piu') una chiave surrogata?
Mi riferivo all'"invece": usarla in più non ha senso.
Il vantaggio è, ovviamente IMHO e _in relazione a questo caso
particolare_ (competenze e linguaggio usato), nel fatto che l'OP non
dovrebbe scriversi il codice che genera la chiave primaria. In fase di
inserimento se ne occuperebbe il db, in caso di aggiornamento del
record gli basterebbe una sola variabile.
In caso contrario potrebbe usare un campo univoco, tipo il codice
fiscale (sulla cui unicita' si potrebbe discutere), come chiave
primaria per gli utenti.
Ma gia' negli altri casi (societa' e comitato) la scelta su quale
campo usare come chiave diventa piu' nebulosa. Nel primo caso il
codice fiscale o la PIVA, nel secondo comunque un codice generico.
Usando gli autoincrementanti avrebbe una situazione piu' omogenea.
Ciao,
Paolo

 direttamente nel motore di qualsiasi DB.
Con "gestione della duplicazione delle chiavi" vuoi dire che vengono
segnalati come errori gli inserimenti di chiavi duplicate?
Pero' la verifica a monte tocca sempre allo sviluppatore, e puo'
essere macchinosa se la chiave e' composta di parecchi campi
(purtroppo ho gia' visto tabelle di 15 campi in cui 12 erano nella
chiave, ma qui passiamo nel patologico ;-)
Ciao,
Paolo

 Usando gli autoincrementanti avrebbe una situazione piu' omogenea.
Aprendo il database ai doppioni, pero'.
bye

 
La verifica la fai sulla validazione dei campi, non e' pensabile la 
validazione della chiave a priopri, ammenoche' non sussistano 
particolari problematiche.
Alla prossima.
	MAX

 Aprendo il database ai doppioni, pero'.
Si'.
Si puo' ovviare utilizzando degli altri indici univoci, oltre alla 
chiave, ma temo che questo vada altre le competenze dichiarate dall'OP.
Ciao,
Paolo

 particolari problematiche.
Io di solito effettuo a priori sia la validazione dei campi che le 
verifiche sulla chiave: per valutare se procedere con una insert o una 
update prima effettuo una select per vedere se la chiave e' gia' presente.
Sinceramente e' un approccio che, negli anni, ho visto con diversi 
linguaggi e in ambienti diversi, non mi pare insensato.
Ciao,
Paolo

 
Non ho detto che e' insensato, ho detto che dipende dalle problematiche.
In alcuni casi la stessa tecnica la utilizzo anche io, in altri ho 
provato ad usarne un'altra.
E funzionano entrambe.
Buona giornata.
	MAX
p.s. l'altro metodo e':
1) validazione dei campi.
2) scritture dei dati
3) se errore update
	altrimenti insert.
Ariciao :)

 stato cambiato.
Per quanto cambiare una chiave sia assai sgradevole (ma per questo
si dovrebbe eventualmente biasimare l'amministrazione), non e'
la stessa cosa che dire che il CF non sia univoco.
bye

 la stessa cosa che dire che il CF non sia univoco.
Ora non ricordo con precisione assoluta, e' passato qualche anno (in 
caso posso cercare i riferimenti), ma e' solo dal 1995 che il ministero 
delle finanze garantisce l'unicità del CF.
Quelli duplicati emessi in data precedente dovrebbero essere stati tutti 
sostituiti, ma a questo proposito non e' mai stata pubblicata una 
dichiarazione ufficiale.
Ovviamente sono sofismi, visto che i casi eventualmente possibili sono 
piu' che rari.
Ciao,
Paolo

 [...]
Il primo metodo mi sembra piu' corretto sul piano teorico, almeno per 
due motivi:
- un'eccezione, proprio in quanto tale, dovrebbe essere gestita come un 
caso anomalo, e non come un pattern prestabilito;
- molti linguaggi (tra cui il VB, usato dall'OP) hanno una mediocre 
gestione degli errori/eccezioni.
Ciao,
Paolo

 Poi, per carita', una risposta non la si nega a nessuno.
Concordo che taluni messaggi seguono un particolare pattern, ma
non saprei se era questo che intendevi.
Mi torna in mente un commento attribuito a Chris Date su talune
richieste fatte nei NG; lui le categorizza sotto il tipo
"I don't know how to do my job and am looking for somebody to
do it for me". Trovo curioso che persino il massimo esperto di db
sia colpito dal fenomeno.
Periodicamente anche qui appaiono, da utenti occasionali, richieste
del tipo fico-cascami-in-bocca; anche se indirizzati verso le
relative letture, spesso la risposta e' "Se volevo leggere non
chiedevo".
Questo rende chiaro che costoro non sono realmente interessati ad
imparare, ma cercano qualcuno a cui scaricare il barile.
Caso limite, ma che riassume tutti, quello dello studente che a due
giorni dall'esame chiedeva qui come scrivere query...
bye

 
In questo NG no di sicuro.
Prova a leggere i.c.w.php per esempio.
Ciao.
	MAX

 
Esatto, hai perfettamente reso l'idea.
Alla prossima.
	MAX