[SQL] Relazioni circolari

[Mex87]

Salve ragazzi, è da un po di tempo che non progetto database e sono un po arrugginito.

Ho delle foto di 1°Livello a cui posso associare dei punti ed ad ogni punto posso associare delle foto di 2°Livello, a sua volta ad ogni foto di 2° livello posso associare più punti a cui posso associare delle foto di 3° livello.

ricapitolando ho 4 livelli di foto ed ogni foto può contenere più foto del livello successivo


1L -> 2L -> 3L -> 4L
-> 2L
-> 2L -> 3L
-> 3L -> 4L
-> 3L -> 4L


Non so se sviluppare tutto usando una tabella per livello o usando una tabella unica, perchè alla fine le foto hanno tutte gli stessi dati, l'unica cosa che cambia è proprio il livello.

Qualche idea?

[Mex87]

Ci ho riflettuto un po ed ho tirato fuori questa possibile soluzione:
Dato che i dati generali per tutti i livelli sono sempre quelli ho pensato di creare una tabella immagine che le contiene tutte, in questo modo se devo collegare altre tabelle alle immagini uso un solo indice.

Poi creo 4 tabelle separate Livello1,2,3 e 4 che come chiave primaria useranno l'id della tabella immagine, l'id dell'immagine di livello precedente a cui è collegata più alcuni dati specifici per ogni livello.

In questo modo non ho più una relazione circolare e non complico troppo la base di dati.

Dovrebbe essere una buona soluzione, voi che ne dite? :D

[BlackAuron]

Sostanzialmente quello che vuoi e' costruire un albero con profondita' massima 4.
Personalmente, quello che farei e' creare due tabelle:
1. la prima tabella contiene una lista delle immagini, con id e livello dell'immagine

Id | Nome_Immagine | Livello

2. La seconda tabella contiene le relazioni tra le immagini. Una colonna per l'id del nodo "padre", e una colonna per il nodo figlio:

Id_Padre | Id_Figlio

entrambe foreign key che puntano all'id della prima tabella, e con il constraint aggiuntivo che livello figlio - livello padre = 1.

Se il constraint e' un problema, puoi spostare la logica per crearlo nel domain dell'applicazione, e il che renderebbe tutto pure piu' chiaro.
Nota che con un approccio del genere, non sei limitato ad avere 4 livelli, in teoria potresti costruire un albero di profondita' N con minimi cambiamenti.

Nel tuo esempio, la prima tabella sara' qualcosa del tipo


Id | Nome_Immagine | Livello
1 | a | 1
2 | b | 2
3 | c | 2
4 | d | 2
5 | e | 3
6 | f | 3
7 | g | 3
8 | h | 3
9 | i | 4
10 | j | 4
11 | k | 4


mentre la seconda tabella risultera':

Id_Padre | Id_Figlio
1 | 2
1 | 3
1 | 4
2 | 5
4 | 6
4 | 7
4 | 8
4 | 6
4 | 7
4 | 8
5 | 9
7 | 10
8 | 11

[Mex87]

Ciao, grazie per la risposta, che è molto simile alla mia prima idea, che ho scartato, semplicemente perché non mi sembra corretta, in questo modo creo dei cicli all'interno del db, è molto probabile che mi sbagli :confused: non mi ricordo la teoria al momento :muro:

[BlackAuron]

Se aggiungi il constraint che livello figlio - livello padre deve essere uguale ad 1, non vedo onestamente come si possano creare dei cicli. Inoltre, se una immagine di livello 1 puo' puntare direttamente ad una di livello 4, puoi rilassare il constraint ponendolo > 0 piuttosto che =1, sempre senza il rischio di creare cicli di sorta.

Detto questo, pure se creare il constraint fosse impossibile ( alcune db engines non permetto di avere subqueries all'interno di un check), credo che il controllo del livello sia perfettamente delegabile al domain dell'applicazione ( e probabilmente e' li che dovrebbe stare).

[Zeppe79]

Non so se ho capito bene la tua situazione e sono un po' arrugginito anch'io, però potresti creare un unica tabella con: id | immagine | id_genitore. Dove id_genitore si riferisce all'id di un'altra immagine sulla stessa tabella.
Se id_genitore = NULL, allora l'immagine è di primo livello, altrimenti cerchi il genitore: se il genitore ha id_genitore = NULL allora il genitore è di primo livello e l'immagine originale è di secondo livello, altrimenti c'è anche un nonno heheeh !!! E risali l'albero fino a quando trovi id_genitore = null.
La difficoltà maggiore è nel costruire query che ti restituiscano immagini di 2,3 o 4 livello, ma potrebbe essere una cosa del tipo:

immagini di primo livello = select * from immagini where id_genitore IS NULL
immagini di secondo livello = select * from immagini where id_genitore in (select id from immagini where id_genitore IS NULL )
immagini di terzo livello = select * from immagini where id_genitore in ( select id from immagini where id_genitore in (select id from immagini where id_genitore IS NULL )
)

Non so se fa al caso tuo, però è un approccio differente.

[bio82]

io utilizzo questo schema per la creazione dei menù:

id--nome--quellochevuoi--rid

rid definisce chi è il padre...non so a che livello un menù si trova..e non mi interessa...

recupero tutti i dati (filtrati per le auth dell'utente) con una sola query e poi costruisco un albero lato codice e lo attacco al menù...puoi tranquillamente fare una cosa simile...

fai tutti con una tabella sola soprattutto....poi limiti lato sw il numero di livelli...

più o meno faccio come spiegato qui:
http://www.thinqlinq.com/Post.aspx/Title/Hierarchical-Trees-from-Flat-Tables-using-LINQ

bio

[Mex87]

Ragazzi, grazie per i consigli, alla fine ho fatto come consigliavate voi, con una tabella che contiene tutte le immagini ed una che contiene le relazioni tra loro e limito il numero di livelli via software. :D

Grazie ancora!