Newsgroup: it.comp.software.database
Titolo: Iscritti & hobbies... continuate ad aiutarmi, vi prego! :)

salve ragazzi, spero siate disponibili come la volta scorsa, e se dico 
orribili castronerie me lo facciate notare, OVVIAMENTE, ma senza sparare, 
visto che ehm come sapete mi trovo piů a mio agio con le ricette che con i 
database... ;)
Dunque, tornando al mio db MySQL di prova, con gli iscritti ad un sito web 
che praticano diversi hobbies, ecco quel poco che per il momento ho buttato 
giů; chissŕ se potreste gentilmente dirmi dovąč che ho fatto giusto e dove ho 
invece sbagliato?
(sperando di aver azzeccato almeno qualcosa...!)
Ordunque, ho, per ora, nel db:
TAB_ISCRITTI
id_iscritto  ............./ TINYINT(5) UNSIGNED ZEROFILL   <‹la PK della 
tabella
nickname  ../  VARCHAR(30)
nome  ........./  VARCHAR(30)
cognome  .../  VARCHAR(30)
indirizzo ....../  VARCHAR(100)
TAB_CITTAą
id_cittaą (CAP?) ../ TINYINT(5) UNSIGNED ZEROFILL   <‹la PK della tabella
cittaą .................../  VARCHAR(50)     
provincia ............/   VARCHAR(30)
regione ............../   VARCHAR(20)
Stato ................./   VARCHAR(30)
TAB_HOBBIES
id_hobby  ............../ TINYINT(3) UNSIGNED ZEROFILL   <‹la PK della 
tabella
bridge  ........../ ?
giardinaggio ../?
golf ................/?
calcetto ......../?
scacchi ........./?
(ecc.ecc.ecc.)
ho ancora dubbii come vedete ma spero che fino a qui sia (quasi) giusto... 
uhm... ż ;) ?
Poi, se ho ben capito, debbo fare unąaltra tabella con tutti gli id.
(invece io credevo che questa tabella relazionale MySQL la creasse come dire 
al volo a partire dalle diverse query... con JOIN, oppure UNION...) 
nel mio caso:
TAB_ID
id_iscritto
id_cittaą
id_hobby
E forse una prima query di interrogazione al mio db potrebbe 
essere(???!!!!???):
SELECT id_hobby '001ą FROM TAB_ID WHERE id_cittaą=ą00100ą
in questo modo (spero!) troverei tutti gli appassionati di bridge della cittŕ 
di Roma (sempreché sia giusto utilizzare il CAP cosa della quale dubito 
fortemente, ma lo tengo buono per ląesempio...)
o eą assolutamente sbagliato, e sono ancora nella nebbia piuą fitta, 
nonostante i buoni consigli di freCho, Andrea, e The man with two watches...?
sigh...
spero in altri lumi da parte dei GURU dei database...
ciao!
:-)
alcina
P.S. ho visto che esiste un programma, DbDesigner, ma č per windows o linux e 
io sono su mac; esiste che voi sappiate qualcosa di analogo anche su MacOsX?
Grazie!
================================================================
 Hogwasher: You don't have to sacrifice friendliness for power
 
http://www.asar.com/cgi-bin/product.pl?58/hogwasher.html
 
================================================================

Io vedrei meglio
TAB_ANAGRAFICA
 id_iscritto  ............./ INTEGER (chiave primaria)
 nickname  ../  VARCHAR(30)
 nome  ........./  VARCHAR(30)
 cognome  .../  VARCHAR(30)
 indirizzo ....../  VARCHAR(100)
 provincia ............/   VARCHAR(30)
 regione ............../   VARCHAR(20)
 Stato ................./   VARCHAR(30)
 Cap ....
ect ect tutti i dati che potrebbe richiedere un anagrafica
TAB_HOBBIES
id_hobby  ............../ INTEGER (chiave primaria)
id_Anagrafica INTEGER
Hobby VARCHAR (30)
Notevarie MEMO
.....
Anagrafica e hobby sono legati tra loro da id_Anagrafica
in questo modo ti dovresti trovare 2 tabelle del tipo:
ANAGRAFICA
| ID  | NICK | CITTA     | NOME   |
|-----|--------|-----------|-----------|
|  1   | pippo   | Milano     | Mario
|  2   | pluto    |Roma        | Stefano
|  3   | topo    |Torino       | Antonio
|  4   | papero|Roma        | Luigi
HOBBY
| ID  | ID_ANAG | HOBBY       |
|-----|-------------|--------------|
| 1    |  1                | Bridge          |
| 2    |  1                | Nuoto          |
| 3    |  1                | Calcio          |
| 4    |  2                | Bridge          |
| 5    |  2                | Pallavolo      |
| 6    |  3                | Briscola       |
| 7    |  4                | Bridge         |
la prima query
Select TAB_ANAGRAFICA.nickname,TAB_ANAGRAFICA.nome  from TAB_ANAGRAFICA left
join  TAB_HOBBIES on (TAB_ANAGRAFICA.id_iscritto= TAB_HOBBIES.id_Anagrafica)
where citta=:sCitta and TAB_HOBBIES.Hobby=:sHobby
Ovviamente nella select ci puoi mettere tutti i campi che vuoi.
Dove i parametri :sCitta  e :sHobby li passi tu a tua scelta
Passando :sCitta = 'Roma' e :sHobby='Bridge' avrai un result del tipo
| NICKNAME  |  NOME       |
|----------------|--------------|
| pluto                | Stefano        |
| papero             | Luigi            |
Non essendo un "guru" spero, se ho detto qualche cavolata, di essere
corretto
Saluti
Goblin

 Grazie!
dbdesigner c'e' sia per linux che per windows, e qundi dovrebbe
funzionare anche su macosx (la versione per linux intendo)

 ect ect tutti i dati che potrebbe richiedere un anagrafica
avevo messo 2 tabelle perche' sul libriccino che ho letto (un pocket 
Apogeo) dicono di fare cosi'... cito:
"La terza forma normale prevede l'eliminazione di tutte le dipendenze 
esistenti all'interno di una tabella che siano riferite a campi che non 
sono campi chiave. Una dipendenza viene generata quando due o più campi 
sono collegati tra loro in modo univoco nella stessa tabella.
Un segno di dipendenza che non è riferita a campi chiave è una tabella 
che contiene dati anagrafici di persone insieme con il loro indirizzo, 
citta', provincia e Stato di residenza.
Dato un campo città gli altri due campi provincia e stato di residenza 
sono dipendenti dal primo."
A questo bibitone di cui avevo capito poco a dire il vero segue 
pero'l'esempio pratico, (che io ho preso paro paro!), una tabella 
anagrafica con tutto che lui scinde in due... e scrive:
"In questo esempio, per applicare la terza forma normale, è sufficiente 
togliere i campi città, provincia e stato, per inserirli in una nuova 
tabella CITTA' e collegare le due tabelle con una relazione impostata 
sul codice della citta'."
Allora adesso non so chi ha ragione... :-)

grazie per la risposta Goblin, ora ci mediterò su...
:)
alcina

 
hai ragione, ma sono su un vecchio osX e dovrei installare una specie di 
"pacchetto" per poter usare le applicazioni linux...
e io sono un po' imbranata...
ma ora mi ha risposto uno dei progettatori, e seguendo il suo consiglio 
ho scaricato un altro loro software, per il momento in versione beta, da 
qui:
http://dev.mysql.com/downloads/workbench/1.0.html
c'è per tutte le piattaforme :)
Ti ringrazio per la tua gentile risposta!
ciao,
:) alcina

 alcina

 :) alcina
Ciao Alcina... si dice progettisti! :-)
Ciao
Giulio

 Giulio
hai ragione, dopo dieci anni di Francia non so ancora parlare francese e non 
so piu' parlare italiano, scusa!
:-)
ciao,
alcina
==============================================================
 Posted with Hogwasher. Mac first, Mac only:
 
http://www.asar.com/cgi-bin/product.pl?58/hogwasher.html
 
==============================================================

 faccia notare se ho scritto stupidaggini
Chi inizia bene è già a metà strada, e per il data modeling, il resto
è pure in discesa.
Se vuoi, resta in zona, che qui il "lavoro" non manca :-)
Cordialmente saluto

 molto più naturale, vero!
:)
e' questo il motivo per cui ti consiglio di pensare a come organizzare
i tuoi dati secondo uno schema naturale e poi applicarle allo schema del
DB, puoi ottenere solo vantaggi
(nell'esempio di sopra se avessi utilizzato un id numerico per gli hobby
saresti stata costretta ad un ulteriore join per cercare "bridge" nel
campo nomehobby)
buone riflessioni :)

 Cordialmente saluto
ricambio il saluto e ringrazio :)

 :) alcina
Ciao.
aggiungo solo a questo perchè in fin dei conti è quanto
ti avevo risposto sinteticamente nel thread della settimana scorsa e che mi
è valso un pranzo a Nizza  :) 
La tua idea iniziale è stata quella di avere la tabella hobbies
formata da un identificativo e poi da tante colonne quanti i possibili
hobbies. L'errore di base di questa impostazione è che devi prevedere
in anticipo tutti i possibili valori (impossibile e limitativo) e avresti poi
sicuramente molti campi vuoti in ogni record (ossia tutti gli hobbies
meno quelli effettivamente praticati dall'iscritto).
L'approccio corretto potrebbe essere creare invece la tabella con un
identificativo (e va benissimo il nome dell'hobby) e al limite dei campi aggiuntivi
nel caso volessi fare delle statistiche particolari:
es. potrebbe interessarti se l'hobby è uno sport di squadra o individuale,
il livello di bravura dell'iscritto (amatoriale, professionista, 
campione del mondo) ecc.ecc.
Poi se si va nel dettaglio, anche questa soluzione è un compromesso,
perchè ci  sono hobbies che non hanno nulla a che vedere con lo sport
(suonare uno strumento per es) e quindi la colonna relativa che ne
specifica se di squadra o meno resterebbe inutilizzata e così via.
Però come prima stesura di uno schema di db mi pare che vada benone.
Ovviamente ci sarà una terza tabella che metta in relazione gli
identificativi dell'iscritto con l'hobby praticato. Al limite, qualora
l'iscritto ne abbia più di uno ci saranno più record, ma questo non è
assolutamnte un problema, dato che l'identificativo dell'iscritto è
univoco e perciò una query con la "where condition" id_iscritto = 'xxxx' 
ti trova tutti gli hobbies del soggetto.
spero di essere stato più chiaro.
ciao

 buone riflessioni :)
ehhh si' prima di poterti rispondere davvero mi toccherà masticare e digerire 
il tutto per un buon paio di settimane... :)
ciao e grazie ancora!


 ciao
tu sei chiaro, sono io che capisco poco ;-)
grazie e ciao!


 
di nulla
ciao

 database, giocare a golf?
l'handicap? aargh! questi poi sono dati s e n s i b i l i :)
quanto al fatto che ti "toccherà masticare e digerire il tutto per un buon 
paio di settimane... :)"
tu non hai idea di quanto possano essere affamati i db'ers. ti tocchera' 
anche farli masticare e digerire... :)
ciao, a.

 tabella
Uno: il CAP (Codice di Avviamento Postale) dev'essere sempre e comunque
un campo stringa, in quanto e' composto da 5 cifre che vanno dallo zero
al nove.
Due: il campo CAP non puo' essere chiave primaria, in quanto non e'
univoco (e.g. Roma ha piu' CAP, oppure lo stesso CAP e' associato a
piu' localita')
Enrico

 alcina
:-)
Ciao

 l'handicap? aargh! questi poi sono dati s e n s i b i l i :)
No. Non e` quello che pensi tu. :)
L'handicap, nel golf, e` una specie di "grado di bravura". Lo usano per
pareggiare i giocatori professionisti con i principianti.
Bye.
-- 
Alessandro Pellizzari

 pareggiare i giocatori professionisti con i principianti.
ehm, avevo messo faccine qua e la'...
ciao, a.