Newsgroup: it.comp.software.database
Titolo: Struttura database gerarchico + tabella dettagli

Salve,
sto cercando di trovare la soluzione migliore per un problema logico di
strutturazione di tabelle.
Le due soluzioni che al momento ho trovato sono le seguenti:
http://setecastronomy.stufftoread.com/go.php?ID=30
L'esempio e' fittizio ma conforme alle necessita'.
In pratica si tratta di una struttura di tre (o piu' tabelle) collegate
ognuna da una relazione padre figlio (Stato -> Regione -> Provincia). A
queste tre tabelle vorrei poter colegare una serie di record di una
tabella contenente i dettagli (ad esempio le statistiche delle etnie).
Quello che non voglio fare e' avere una tabella per ogni tabella della
struttura (ossia una tabella di dettaglio per gli Stati, una per le
regioni e cosi' via).
Quali soluzioni alternative posso seguire?
Grazie.
-- 
I am what I am, I do what I can
Cerchi un programmatore PHP/MySQL? 
http://url.repository.biz/go/1Y
L'uomo, conscio di sbagliare, persevera.

 Grazie.
HTH
Saluti
-- 
Stefano Zamboni - 
zam...@freemail.it
Leggi di Manubay per i programmatori:
1) Se la modifica di un programmatore a un programma esistente funziona,
probabilmente non era quello che voleva il cliente.
2) Il cliente non sa quello che vuole, ma sa quello che non vuole.

 strutturata in questa maniera (esempio):
L'esempio delle "zone" e' fittizio, le tre tabelle devono restare
separate in quanto contengono dati non omogenei e logicamente da
mantenere separati.


 Quali soluzioni alternative posso seguire?
Io mi terrei le tre tabelle padre collegando semplicemente la IDprovincia a 
IDkey e siccome ogni provincia appartiene ad una regione e ogni regione ad 
ad uno stato il problema è risolto.
Se le zone con cui lavori sono poche e non giustificano le tabelle padre di 
stato-regione-provincia potresti creare una unica tabella provincia o zona 
con un campo descrittivo della regione e dello stato di appartenenza.
Ciao, Angelo.
-- 
        Powered by Debian Woody
 [Linux Registered User # 341564]

 di appartenenza.
[mi quoto]
L'esempio delle "zone" e' fittizio
[/quoto]
La tabella dei dettagli in questo caso "tblEtine" contiene dati che
dovranno essere correlati ad una delle tre tabelle della gerarchia.


 dovranno essere correlati ad una delle tre tabelle della gerarchia.
Perchè non collegarlo solo alla provincia?


 Perchè non collegarlo solo alla provincia?
Perche' i dati contenuti nella tabella dei dettagli (es. tblEtnie) DEVE
essere collegata (in qualche modo) ad ogni tabella della gerarchia.


 
di niente :-)
Ciao
-- 
Stefano Lixi
Cagliari
email: 
i_conico-at-yahoo.it

 
Con gli stessi dubbi mi e' venuta in mente un'altra possibilita', usando 
le lingue al posto delle etnie non credo cambi molto l'esempio.
Es. l'albanese (idlingua=2), parlato in Albania(idStato=4) e in qualche 
provincia italiana (idProv={1,2,3}) (Stato - province), l'Italiano 
(idLingua=1), parlato in Italia (idStato=1)e nel Canton Ticino 
(idRegione=4)(stato - regione(?)), e il gaelico (idLingua 3) parlato in 
regioni sparse di vari stati.. (idRegione={1,2,5,8})
Potresti usare in questo caso una sola tabella {idlingua, idStato, 
idRegione, idProvincia} che, per l'esempio indicato sarebbe popolata in 
questo modo:
idlingua | idStato | idRegione | idProvincia
--------------------------------------------
        2 |        2|           |
        2 |         |           |           1
        2 |         |           |           2
        2 |         |           |           3
        1 |        1|           |
        1 |        1|          4|
        3 |         |          1|
        3 |         |          2|
        3 |         |          5|
        3 |         |          8|
.... dove, ovviamente, gli id sono dati a caso.
In questo modo hai un'unica tabella dove sono salvate le varie relazioni 
e comunque non rimani legato alla relazione gerarchica tra stato , 
regione e provincia.


 tre regioni e 10 province.. E' questo il problema?
No. La tabella "tblEtnie" non contiene l'elenco delle etinie, ma dei
dati statistici relativi le etnie riferili ad una delle "zone".
IL problema risiede cu come implementare nel modo piu' efficiente e
normalizzato questa relazione.


 in questo modo: 
Questa e' la soluzione B che avevo gia' valutato.
http://setecastronomy.stufftoread.com/go.php?ID=30


  
Chiedo scusa per il messaggio inutile di prima,quello che riportava la 
tua stessa idea.
Propongo un'altra idea poi, giuro, per oggi la smetto.
Puoi intervenire sul lato Stati/regioni/province (*)? Ho visto che 
almeno regioni e province hanno la stessa struttura.
Perche' allora non fare un'unica tabella Aree (idArea, tipo = 
{stato|regione|provincia}, idPadre, descrizione) dove la relazione padre 
e figlio e' stabilita tra record della stessa tabella?
In questo modo non hai bisogno del campo KeyType perche' il 
riconoscimento del tipo dell'area lo  fai direttamente dalla tabella
Aree, ti ritovi cioe' con un link tra due sole tabelle, e per 
specializzare una ricerca basta una clausola nella where sul tipo 
dell'area.
Altri pensieri che sto facendo mi riportano sempre alla tua soluzione B, 
e non e' il caso che te la posti di nuovo...
(*) No perche' il database esiste gia' e non puoi intervenire sulla 
struttura preesistente.....
Ciao, torno a cercare lavoro.....


 Ho visto che almeno regioni e province hanno la stessa struttura.
[mi quoto]
le tre tabelle devono restare separate in quanto contengono dati non
omogenei e logicamente da mantenere separati.
[/quoto]


 strutturazione di tabelle.
Dal momento che mi sono arreso..
Sarei curioso di sapere se/come l'hai risolta.
Grazie


 Sarei curioso di sapere se/come l'hai risolta.
Soluzione B.
-- 
I am what I am, I do what I can
