Alle Verbindungen finden

Stpla

Neuer Benutzer
Beiträge
3
Hallo,

ich habe eine Tabelle mit Aufgaben:

ID|Aufgabe
1|Kartoffeln schälen
2|Wasser kochen
3|Teig kneten
4|Eier braten
5|Salat waschen
6|Zwiebeln hacken
usw.

Anwender können nun Aufgaben beliebig miteinander verbinden:
ID|Aufgabe1|Aufgabe2
1|2|4
2|5|1
3|3|4
4|4|1
5|2|6
usw.

Wenn nun eine Aufgabe ausgewählt wird, sollen alle verbundenen Aufgaben angezeigt werden. Das ist kein Problem. Wählt der Anwender also beispielsweise Aufgabe 4 aus werden ihm als verbundene Aufgaben 1,2 und 3 angezeigt.
1|2|4
3|3|4
4|4|1

z. B. ...where Aufgabe1=4 or Aufgabe2=4

Nun möchte ich aber dem Anwender ALLE verbundenen Aufgaben anzeigen. Das heißt, wenn er Aufgabe 4 auswählt, sollen nicht nur die Aufgaben 1,2 und 3 angezeigt werden, sondern auch die Aufgabe 5, weil sie mit Aufgabe 1 verbunden ist, also über diesen Umweg auch mit Aufgabe 4.
1|2|4
2|5|1->5 ist mit 1 verbunden
3|3|4
4|4|1->1 ist mit 4 verbunden

Das müsste dazu führen, dass, egal welche Aufgabe der Anwender aus diesen 4 Datensätzen auswählt, immer alle 4 angezeigt werden. Aufgabe 2 ist mit Aufgabe 4 verbunden, deshalb müssten auch alle Aufgaben angezeigt werden, die mit Aufgabe 4 verbunden sind usw.

Mir fällt dazu keine vernünftige Lösung ein (außer natürlich, dazu einen Algorithmus zu schreiben), wie man das mit SQL abfragen könnte. Geht das überhaupt?

Vielen Dank für eure Mühe
Stpla
 
Werbung:
Das sieht nach einem Designfehler aus.
Du willst meistens nie mehr als eine Spalte haben, um das gleiche abzubilden.
Beschäftige Dich mit Normalisierung!
 
Danke für deine Antwort.
Das mit dem Designfehler habe ich auch schon überlegt.
Wie müssten denn dann die Tabellen aussehen?

Tabelle Aufgaben:
ID|Aufgabe
1|Kartoffeln schälen
2|Wasser kochen
3|Teig kneten
.
.
.

Tabelle Verbindungen:
?????

Ähnlich wäre es doch auch mit sozialen Netzwerken oder Verwandschaftsbeziehungen, oder nicht? Wie macht man es denn da? Also X kennt Y und Z, Y kennt A, also kennt X über einen Umweg (nämlich Y) auch A.
 
Zuletzt bearbeitet:
Alles was an Datenzuwachs zu erwarten ist, gehört in Listenform (aus menschlicher Sicht), also eine Aufgabenliste in diesem Fall. Man würde wahrscheinlich die Aufgaben in der Folge, wie sie abzuarbeiten sind in eine Liste schreiben, untereinander. Das ist jenseits von EDV eine ganz normale Praxis.
Wenn Du das überträgst in ein Modell, dann brauchst Du für einen Ablauf, ein Aufgabenpaket technisch gesehen Selbstreferenzierung. Im einfachsten Fall bekommt die Aufgabensammlung ein Feld, das jeder Aufgabe den Verweis auf die vorigen Aufgabe ermöglicht.
Das wird durch ein Fremdschlüssel realisiert, der eigentlich nicht so fremd ist, sondern auf den PK der eigenen Tabelle zeigt.

Tabelle Aufgaben
ID Bigint, PK
Paket_ID Bigint, FK > Aufgabenpaket
Name varchar,
vorige_ID Bigint, FK > Aufgaben.ID
Die erste Aufgabe ist damit ohne einen Wert in vorige_ID und so auch einfach als solche zu erkennen.
 
Danke erstmal für deine Mühe.

Das mit den Aufgaben war, glaube ich, ein blödes Beispiel von mir. Was du aufzeigst, ist doch eine verkette Liste, oder nicht?

Ich versuche mich mal an einem anderen Beispiel:
Personen:

ID|Name|Straße|Ort|...
1|Petra|...
2|Hans|...
3|Else|...
4|Michael|...
...

Diese Personen haben zunächst nichts miteinander zu tun. Nun lernt Petra den Michael kennen. Das möchte ich irgendwie in Datenform abbilden.
Petra kennt jetzt Michael:
1|4
nun lernt Petra auch noch Else kennen:
1|3
Else kennt schon Hans:
3|2
Das wäre ja keine verkette Liste, da Personen mehrere Personen kennen können, andere hingegen gar keine. Wie müsste man das in Tabellenform anlegen? Mir würde halt eine klassische M:N-Tabelle einfallen:

ID|wer|kennt wen
1|1|4
2|1|3
3|3|2
...

Sorry nochmal für das blöde Beispiel mit den Aufgaben.
 
Werbung:
Zurück
Oben