Se A = B e B = C allora A = C

[RikBen]

Ciao a tutti,
chiedo consiglio per come impostare in SQL la seguente problematica.
Devo gestire degli 'articoli equivalenti', ovvero dei prodotti che, pur avendo un codice diverso, sono in realtà lo stesso oggetto.
Il sitema mi deve far inserire degli equivalenti in una tabella di equivalenti, appunto, composta da due campi: CodArt e CodEqu. Ovviamente può avere più record.

Dato poi che la procedura quando deve gestire gli equivalenti consulta la tabella in entrambi sensi (estrae tutti gli equivalenti per Articolo = CodArt e poi per Articolo = CodEqu), la tabella accetta i dati senza alcun controllo.

Il problema è che, nel caso si verifichi quanto in oggetto, ovvero se A = B e B = C allora A = C, che si traduce in:
CodArt CodEqu
A B
B C
Io dovrei fare in modo che la query ritorni:
A B
A C
B A
B C
C A
C B
In modo che, mettendola in join con uno specifico Articolo, mi escano tutti i possibili equivalenti.

Qualche idea geniale ?

[br1]

Dato che il ciclo potrebbe stendersi all'infinito ( a=b, b=c, c=d quindi a=d ) il consiglio e' di "promuovere" uno dei codici a principale e associare tutte le "uguaglianze" a quel solo codice... in soldoni posto a come codice principale registrare le uguaglianze come a=b, a=c, a=d eccetera.

A pensarci bene basta aggiungere una query in fase di inserimento ma poi si semplifica enormemente in ricerca...

IMHO ovviamente

[RikBen]

A pensarci bene basta aggiungere una query in fase di inserimento ma poi si semplifica enormemente in ricerca...

Giusto, logica deduzione, ma effettivamente non ho specificato un dettaglio importante...
Mi trovo i dati già organizzati così !

[in the web]

Di fatto è un albero. Per sapere come estrarre dati dagli alberi con delle query SQL, vedi queste slide:
http://www.slideshare.net/ehildebran...archies-in-sql

Se tu avessi scritto quale DBMS usi, può darsi che nel tuo DBMS ci siano comandi specifici per leggere gli alberi.

Consiglio comunque di usare una delle tecniche descritta nelle slide (o una delle tecniche native del tuo DBMS) per arrivare alla situazione descritta da br1. Questo migliorerà molto le performance.

[RikBen]

Originariamente inviato da in the web

Se tu avessi scritto quale DBMS usi, può darsi che nel tuo DBMS ci siano comandi specifici per leggere gli alberi.

Mssql 2005/2008, ma potenzialmente non solo, quindi meglio una soluzione generica.

Consiglio comunque di usare una delle tecniche descritta nelle slide (o una delle tecniche native del tuo DBMS) per arrivare alla situazione descritta da br1. Questo migliorerà molto le performance.

Il problema é che non c'è gerarchia, non c'è un 'padre' e un 'figlio' definiti perché il dataentri non era controllato ma libero.
E' una relazione molti-molti fra i records.

[in the web]

Accidenti, è un grafo non orientato (o meglio un insieme di grafi)... ci hai postato un problemone, e sul momento non trovo una soluzione accettabile in sql. Spero che questo link ti possa essere utile, magari per scrivere una stored procedure che risolva il problema (creando una situazione come quella descritta sopra da br1):

http://www.ce.unipr.it/people/bertoz...ml/txt211.html

[in the web]

A grandi linee puoi fare così:

* aggiungi una colonna, diciamo "id_unique"
* i = 1 // è l'indice progressivo del grafo
* ciclo su tutti i prodotti
* per ogni prodotto, se è già nella tabella temporanea "visited" passi al prossimo, altrimenti lo metti in questa tabella e continui l'esecuzione
* i++
* nella colonna id_unique del prodotto scrivi il valore di i
* ogni prodotto fa potenzialmente parte di un grafo, e tu lo navighi (vedi slide che ho linkato ieri)
* per ogni prodotto in questo ciclo interno, di nuovo, lo immetti nella tabella "visited" oppure esci. Questo ti permette di evitare i cicli nel grafo (da quello che ho capito sono possibili)
* nella colonna id_unique del prodotto scrivi il valore di i

Spero di essere stato chiaro nella spiegazione e di non aver tralasciato qualche problema.

[RikBen]

Originariamente inviato da in the web
...
* ogni prodotto fa potenzialmente parte di un grafo, e tu lo navighi (vedi slide che ho linkato ieri)
* per ogni prodotto in questo ciclo interno, di nuovo, lo immetti nella tabella "visited" oppure esci.
...

Ti ringrazio molto, in effetti il problema è proprio quello dei loop chiusi, che non mi permettono di far funzionare una classica query CTE risorsiva, tipo distinta-base padre/figlio per eccesso di iterazioni.

Ora proverò a vedere se posso trovare una via in SQl, perchè non credo di poter updatare il record per marcare il flag 'visited' dentro la ricorsione.
Altrimenti, molto più facilmente, lo farò da programma in via procedurale.

Certo che è un bel casino.

[in the web]

Io lo farei con una stored procedure, e gli id dei record già verificati li metterei in una tabella temporanea... così a occhio mi sembra la soluzione più veloce, su sql server

[RikBen]

Originariamente inviato da in the web
Io lo farei con una stored procedure, e gli id dei record già verificati li metterei in una tabella temporanea... così a occhio mi sembra la soluzione più veloce, su sql server

Non riesco a venirne fuori, perchè i nodi non li posso 'navigare' normalmente, in quanto alcune coppie sono scritte al contrario Figlio/padre invece di Padre/Figlio.

Esempio:
A B
A C
A D eccetera, fin qui tutto ok.
B E ok,: E=>B=>A
B F ancora ok... F=>B=>A
D H ok ... H=>D=>A
D K sempre ok... K=>D=>A
L D ... e qui inizia il casino, perchè dovrebbe essere D L !!!
...
H A .. questo poi manda in loop le query CTE perchè richiude la concatenazione di A su H

Pensavo di 'normalizzare' il db prima di riscrivere il programma di dataentry controllato, ma non saprei come determinare i casi 'invertiti' figlio/padre.

Non riesco ad uscirne.