query ricorsive - tabelle autoreferenziali

[ciroteo]

Stavo leggendo qualcosa sull'argomento in oggetto e ho provato a crearmi una
tabella autoreferenziale.
Purtroppo non capisco esattamente lo scopo o la funzione di questo tipo di
costruzione.
In realtà mi sembra che, per certi versi, evitando di effettuare join tra
tabelle diverse, vengano stravolti i criteri di normalizzazione.
Che tipo di utilizzo hanno? In quali contesti sono preferibili?
Per ora ho solo intuito che possono servire quando si hanno n livelli di
dettaglio, ma non mi è molto chiaro.

[MA]

Post by ciroteo
Stavo leggendo qualcosa sull'argomento in oggetto e ho provato a
crearmi una tabella autoreferenziale.
Purtroppo non capisco esattamente lo scopo o la funzione di questo
tipo di costruzione.
In realtà mi sembra che, per certi versi, evitando di effettuare join
tra tabelle diverse, vengano stravolti i criteri di normalizzazione.
Che tipo di utilizzo hanno? In quali contesti sono preferibili?
Per ora ho solo intuito che possono servire quando si hanno n livelli
di dettaglio, ma non mi è molto chiaro.

tabella Anagrafica
codicecliente
RagioneSociale
etc...

tabelle diversadestinazione (un cliente può avere diverse sedi).
o ti crei una tabella uguale con in più il campo rif_codicecliente (il campo
codicecliente può essere usato anche per la sede diversa)

o ti crei il campo rif_codicecliente nella stessa tabella anagrafica.
Ora nel primo caseo è facile immaginare maschera e sottomaschera
nel secondo invece
Metti come origine "select * from anagrafica where isnull(rif_codicecliente)
e la sottomaschera la leghi con quello.
Ora se anche l'esempio non è eccezionale, pensa a mille livelli di un
prodotto finito ed elemento sciolto

[ciroteo]

Post by MA

Post by ciroteo
Stavo leggendo qualcosa sull'argomento in oggetto e ho provato a
crearmi una tabella autoreferenziale.
Purtroppo non capisco esattamente lo scopo o la funzione di questo
tipo di costruzione.
In realtà mi sembra che, per certi versi, evitando di effettuare join
tra tabelle diverse, vengano stravolti i criteri di normalizzazione.
Che tipo di utilizzo hanno? In quali contesti sono preferibili?
Per ora ho solo intuito che possono servire quando si hanno n livelli
di dettaglio, ma non mi è molto chiaro.

tabella Anagrafica
codicecliente
RagioneSociale
etc...
tabelle diversadestinazione (un cliente può avere diverse sedi).
o ti crei una tabella uguale con in più il campo rif_codicecliente (il campo
codicecliente può essere usato anche per la sede diversa)
o ti crei il campo rif_codicecliente nella stessa tabella anagrafica.
Ora nel primo caseo è facile immaginare maschera e sottomaschera
nel secondo invece
Metti come origine "select * from anagrafica where
isnull(rif_codicecliente)
e la sottomaschera la leghi con quello.
Ora se anche l'esempio non è eccezionale, pensa a mille livelli di un
prodotto finito ed elemento sciolto
--

ok MA avevo visto il tuo esempio, e ho capito il meccanismo di creazione.
Ciò che non mi è chiaro è perchè sia preferibile ad una struttura master -
detail.
Per esempio nella mia rubrica aziendale ho fatto tbl principale e tbl
dettaglio per memorizzare i dati dei clienti e i referenti per i singoli
clienti:
p.e. tbl principale: idcomune,comune di milano indirizzo,tel, mail, cel

tbl dettaglio: id,idcomune,dott. Albertini - sindaco indirizzo,tel, mail,cel
ecc...
id,idcomune,dott. Pinco pallino - assessore indirizzo,tel,
mail,cel ecc...

Qui ho n livelli di dettaglio che potrei tranquillamente gestire con
un'autoreferenziale. fin qui ci siamo.

altro esempio:
clienti - servizi - dettaglio servizio

Ogni cliente può commissionarci più servizi e ogni servizio può a sua volta
essere composto da un terzo livello di dettaglio.
p.e.:
clienti:
comune di milano
servizi cliente:
scuola fermi
scuola rossi
scuola bianchi

dettaglio servizi:
scuola fermi : mensa, pulizie, doposcuola.
scuola rossi: mensa, piscina, palestra

In questo caso? Potrei utilizzare solo una tbl, se si come?

[MA]

Post by ciroteo

Post by MA

Post by ciroteo
Stavo leggendo qualcosa sull'argomento in oggetto e ho provato a
crearmi una tabella autoreferenziale.
Purtroppo non capisco esattamente lo scopo o la funzione di questo
tipo di costruzione.
In realtà mi sembra che, per certi versi, evitando di effettuare
join tra tabelle diverse, vengano stravolti i criteri di
normalizzazione. Che tipo di utilizzo hanno? In quali contesti sono
preferibili?
Per ora ho solo intuito che possono servire quando si hanno n
livelli di dettaglio, ma non mi è molto chiaro.

tabella Anagrafica
codicecliente
RagioneSociale
etc...
tabelle diversadestinazione (un cliente può avere diverse sedi).
o ti crei una tabella uguale con in più il campo rif_codicecliente (il campo
codicecliente può essere usato anche per la sede diversa)
o ti crei il campo rif_codicecliente nella stessa tabella anagrafica.
Ora nel primo caseo è facile immaginare maschera e sottomaschera
nel secondo invece
Metti come origine "select * from anagrafica where
isnull(rif_codicecliente)
e la sottomaschera la leghi con quello.
Ora se anche l'esempio non è eccezionale, pensa a mille livelli di un
prodotto finito ed elemento sciolto
--

ok MA avevo visto il tuo esempio, e ho capito il meccanismo di
creazione. Ciò che non mi è chiaro è perchè sia preferibile ad una
struttura master - detail.
Per esempio nella mia rubrica aziendale ho fatto tbl principale e tbl
dettaglio per memorizzare i dati dei clienti e i referenti per i
p.e. tbl principale: idcomune,comune di milano indirizzo,tel, mail, cel
tbl dettaglio: id,idcomune,dott. Albertini - sindaco indirizzo,tel,
mail,cel ecc...
id,idcomune,dott. Pinco pallino - assessore
indirizzo,tel, mail,cel ecc...
Qui ho n livelli di dettaglio che potrei tranquillamente gestire con
un'autoreferenziale. fin qui ci siamo.
clienti - servizi - dettaglio servizio
Ogni cliente può commissionarci più servizi e ogni servizio può a sua
volta essere composto da un terzo livello di dettaglio.
comune di milano
scuola fermi
scuola rossi
scuola bianchi
scuola fermi : mensa, pulizie, doposcuola.
scuola rossi: mensa, piscina, palestra
In questo caso? Potrei utilizzare solo una tbl, se si come?

sono sono due concetti diversi.
l'autorefernziazione nascerebbe se tu avessi scuola fermi come cliente ma
che fattura però il comune di milano
ma il resto è master detail

[ALESSANDRO Baraldi]

Post by ciroteo
Stavo leggendo qualcosa sull'argomento in oggetto e ho provato a crearmi una
tabella autoreferenziale.
Purtroppo non capisco esattamente lo scopo o la funzione di questo tipo di
costruzione.
In realtà mi sembra che, per certi versi, evitando di effettuare join tra
tabelle diverse, vengano stravolti i criteri di normalizzazione.
Che tipo di utilizzo hanno? In quali contesti sono preferibili?
Per ora ho solo intuito che possono servire quando si hanno n livelli di
dettaglio, ma non mi è molto chiaro.
--
ciroteo
MC

L'uso tipico di Self-Reference-Table o Tabelle Autoreferenziate è nella
gestione di Cataloghi di Componenti, dove ogni componente può essere
a sua volta un SottoComponente di un Componente.
Se facessi 2 tabelle(Componente--Dettagli) limiteresti l'esplosione del
componente ad 1 solo Livello
e saresti costretto ad aggiungere una Tabella per ogni livello, ottenendo
una
struttura non Flessibile e statica ed assolutamente non NORMALIZZABILE.

L'uso dell'Autoreferenza è un giochino difficile però, se usi solo 1 Tabella
ti VINCOLA sempre al fatto che un Componente può far parte solo di un
Componente superiore, ed anche questo è un errore da non commettere.

Esempio stupido:

Torta di Mele:
Farina
Uova
Mele

StruDel(non so come si scrive)
Mele
Uova

Come vedi sia mele che Uova fanno parte di entrambi i Componenti.

Ora se tu dovessi fare un gestionale per una pasticceria come
potresti pensare di rendere Flessibile a N livelli la strutturazione
di un Prodotto finito, non certo prevedendo 255 Tabelle.
In realtà ne bastano 2.

La prima con l'Elenco di tutti i Componenti Gestiti, siano elementi finiti
come
la "Torta di Mele" che gli elementi primitivi come le Uova, ed una tabella
Dettagli, nella quale ESPLODI la ricetta dei componenti finiti o
parzialmente
lavorati.

Vediamo le 2 Tabelle:

[TB_COMPONENTI]
(PK) CODICE_COMPONENTE
DESCRIZIONE
TIPO

[TB_DETTAGLI]
(PK) ID_COUNT
CODICE_COMPONENTE_PARENT
CODICE_COMPONENTE
QUANTITA


La Tabella Dettagli avrà un doppio legame con la Tabella Componenti
ottenibile con una Doppia Referenza della Tabella Componenti:
uno lato CODICE_COMPONENTE_PARENT per identificare il Componente
Principale(La torta di Mele) e l'altro CODICE_COMPONENTE per identificare
la Ricetta del CODICE_COMPONENTE_PARENT(Torta di Mele).
Ora capirai facilmente che il Campo TIPO della TB_COMPONENTI serve proprio
per discriminare le cose, una Torta di Mele non potrà mai avere come
Dettaglio una Torta di mele che come Campo[TIPO]=FINITO, ma solo
elementi primi come le Uova o parzialmente lavorati come il PanDiSpagna.

Per quanto riguarda la Normalizzazione, a questo punto ti rendi conto che
questo è esattamente quanto richiede la Normalizzazione.

Ora la parte difficile arriva se devi ottenere la DIBA o DistintaBase, vale
a dire
l'elenco di tutti i Componenti con le Relative Quantità e costi di un
prodotto.
Questa richiesta è all'ordine del giorno per chi fà gestionali e, se
strutturati come
ti ho esposto necessita di funzioni RICORSIVE tutt'altro che banali per
evitare
porcate di codice ed un'estrazione sensata e coerente con le aspettative.

Questo in ogni caso è il sistema migliore di strutturare la cosa. forse un
pò
ostico da affrontare, ma le funzioni di Esplosione per la DIBA sono
abbastanza
semplici, e tieni presente che per la popolazione di TREEVIEW sono
indispensabili
se vuoi evitare inutili perdite di tempo e limiti di Livello.

Saluti