Severin Kacianka: Mehrfache Verbindung

Hallo liebes Forum,

ich schlage mich gerade mit einem (My)SQL Problem herum und sehe derzeit wohl vor lauter Bäumen keinen Wald mehr.
Ich habe eine 'klassiche' n-zu-n Verbindungstabelle die so Aussehen kann:
UID - GID
1   - 1
1   - 2
1   - 3
2   - 2
3   - 1
3   - 2
3   - 3

Wie kann ich mir jetzt alle UIDs anzeigen lassen, von Usern die in allen drein  Gruppen 1 und 2 und 3 sind. Ich glaube ich habe so etwas schon einmal irgendwo gesehen, weiß aber nicht einmal mehr wonach ich suchen soll - bin also für jeden RTFM Link dankbar :-)

Mit lieben Grüßen,
Severin

--
They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
-- Benjamin Franklin
  1. Hallo

    Ich habe eine 'klassiche' n-zu-n Verbindungstabelle die so Aussehen kann:

    m:n-Beziehung bitte.

    UID - GID
    1   - 1
    1   - 2
    1   - 3
    2   - 2
    3   - 1
    3   - 2
    3   - 3

    Wie kann ich mir jetzt alle UIDs anzeigen lassen, von Usern die in allen drein  Gruppen 1 und 2 und 3 sind.

    Wäre ein kombinierter Index über UID und GID eindeutig?
    Geht es Dir um exakt drei Gruppen oder geht es Dir um alle Gruppen, egal wie viele Gruppen es gibt?

    Und dann bitte noch die Angabe der ältesten Version von MySQL, die noch unterstützt werden soll.

    Prinzipiell sollte es eine COUNT DISTINCT mit HAVING und der Prüfung auf 3 tun.

    Freundliche Grüße

    Vinzenz

    1. Hallo Vinzenz,

      Wäre ein kombinierter Index über UID und GID eindeutig?

      Ja: PRIMARY KEY(UID,GID)

      Geht es Dir um exakt drei Gruppen oder geht es Dir um alle Gruppen, egal wie viele Gruppen es gibt?

      die Zahl soll beliebig sein.

      Und dann bitte noch die Angabe der ältesten Version von MySQL, die noch unterstützt werden soll.

      5.0

      Würde dir das SQL-Schema etwas nützen?

      Gruß und vielen Dank,
      Severin

      --
      They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
      -- Benjamin Franklin
  2. Hallo,

    leider ist meine Problembeschreibung nicht ganz richtig. Ich habe eine Liste von Gruppen, die wieder beliebig viele Untergruppen haben können. Auf gleicher Ebene soll immer ein UND gelten, innheralb einer Untergruppe ein ODER:
    1 mit Untergruppe: 11,12,13,14
    2: 21,22,23

    Jetzt will ich fragen koennen:
    Ist User in Gruppe (11 ODER 12 ODER 13) UND (21 OR 22).
    Also muss einen User in beiden 'Hauptgruppen' vorhaben sein.

    Nachdem ich mein OP geschrieben habe habe, dachte ich daran einfach zu zählen, ob der Nutzer in 3 Gruppen ist - das geht aber leider auch nicht gut....

    Gruß,
    Severin

    --
    They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
    -- Benjamin Franklin
    1. Hi,

      Ich habe eine Liste von Gruppen, die wieder beliebig viele Untergruppen haben können. Auf gleicher Ebene soll immer ein UND gelten, innheralb einer Untergruppe ein ODER:
      1 mit Untergruppe: 11,12,13,14
      2: 21,22,23

      Wie hast du diese Info abgelegt?
      Ein Feld, in dem 11, 12, 13 oder 14 drinsteht - und die Zugehoerigkeit zur "Obergruppe" 1 ergibt sich dann daraus, dass alle mit '1' anfangen?

      Jetzt will ich fragen koennen:
      Ist User in Gruppe (11 ODER 12 ODER 13) UND (21 OR 22).
      Also muss einen User in beiden 'Hauptgruppen' vorhaben sein.

      Dann waere es wohl vernuenftiger, Ober- und Untergruppe getrennt abzulegen.

      Nachdem ich mein OP geschrieben habe habe, dachte ich daran einfach zu zählen, ob der Nutzer in 3 Gruppen ist - das geht aber leider auch nicht gut....

      Obergruppen koenntest du dann immer noch recht einfach zaehlen.

      MfG ChrisB

      1. Hallo Chris,

        Wie hast du diese Info abgelegt?

        Hier das SQL-Schema. (Statt GID sind es halt Tags)

        Ein Feld, in dem 11, 12, 13 oder 14 drinsteht - und die Zugehoerigkeit zur "Obergruppe" 1 ergibt sich dann daraus, dass alle mit '1' anfangen?

        Nein.

        Dann waere es wohl vernuenftiger, Ober- und Untergruppe getrennt abzulegen.

        Ich will beliebig viele Untergruppen haben - ist es da wirklich ökonomisch fuer jede Gruppe eine Tabelle zu erstllen?

        Gruß,
        Severin

        --
        They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
        -- Benjamin Franklin
    2. Hallo Severin,

      leider ist meine Problembeschreibung nicht ganz richtig. Ich habe eine Liste von Gruppen, die wieder beliebig viele Untergruppen haben können. Auf gleicher Ebene soll immer ein UND gelten, innheralb einer Untergruppe ein ODER:
      1 mit Untergruppe: 11,12,13,14
      2: 21,22,23

      Dein Schema der relevanten Tabellen mit ein paar Beispieldatensätzen, die ein Ausfiltern ermöglichen, wäre jetzt doch ganz nett. Du weißt, wie Deine Untergruppen realisiert sind, wir wissen es nicht. Du wirst ja hoffentlich nicht den Fehler gemacht haben, Informationen in eine ID zu stecken - so wie es obige Aufzählung nahelegt.

      Freundliche Grüße

      Vinzenz

      1. Hallo Vinzenz,

        Dein Schema der relevanten Tabellen mit ein paar Beispieldatensätzen, die ein Ausfiltern ermöglichen, wäre jetzt doch ganz nett.

        Mit meinen (jetzt einmal auf die schnelle erstellten) Beispieldaten würde ich zB die Person suchen, die mit 3 und 13 getaggt wurde (test2).

        Gruß,
        Severin

        --
        They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
        -- Benjamin Franklin
        1. Hallo Severin,

          Dein Schema der relevanten Tabellen mit ein paar Beispieldatensätzen, die ein Ausfiltern ermöglichen, wäre jetzt doch ganz nett.

          Mit meinen (jetzt einmal auf die schnelle erstellten) Beispieldaten würde ich zB die Person suchen, die mit 3 und 13 getaggt wurde (test2).

          das passt nicht zu Deinen Daten. Ich vermute es fehlt eine zweite Startkategorie und die letzten beiden Datensätze sollten dieser Startkategorie zugeordnet sein.

          Da Du prinzipiell beliebig tief schachteln kannst, hast Du ein Problem. Ich schlage Dir zwei verschiedene Lösungsstrategien vor, Du kannst Dir gern noch weitere überlegen.

          Du könntest Deine Tabellenstruktur komplett über den Haufen werfen und mit "Nested Sets" arbeiten. Informiere Dich darüber und ob Du die Nachteile, den Verwaltungsoverhead beim Einfügen und Abändern, in Kauf nehmen willst. Wenn die Lesezugriffe bei weitem in der Mehrzahl sind, dann wären Nested Sets eine gute Lösung.

          Du könntest Dir andererseits eine Stored Function schreiben, Die Dir zu einem beliebig gewählten Tag den Starttag zurückliefert. Da Du dies rekursiv machen musst, ist es nicht effizient. Ja, Rekursion ist nicht immer effizient.

          Freundliche Grüße

          Vinzenz

          1. Hallo Vinzenz,

            Da Du prinzipiell beliebig tief schachteln kannst, hast Du ein Problem. Ich schlage Dir zwei verschiedene Lösungsstrategien vor, Du kannst Dir gern noch weitere überlegen.

            *sigh* nothing's ever easy... Ich gehe jetzt einmal schlafen und hoffe dass mir im Traum eine schöne Lösung kommt.

            Euch allen einmal vielen Dank für eure Hilfe!

            Gruß,
            Severin

            --
            They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
            -- Benjamin Franklin
          2. Hallo Vinzenz,

            noch eine kleine Nachfrage: Nützt es mir irgendwas, wenn nur die Blätter meines Kategorienbaumes gültige Kategorien sind? Würde es was nützen wenn aus einer Unterkategoriegruppe immer nur eine gültig ist?

            (A OR B) AND (C OR D) es sieht irgendwie so nach einfacher Logik aus - warum ist das nur so komisch.....

            Gruß,
            Severin

            --
            They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
            -- Benjamin Franklin
            1. Hallo,

              noch ein Nachtrag: anscheinend ist es mit SELF-Joins möglich zu den Daten zu kommen:

                
              SELECT * FROM `adressen_tagged` a, `adressen_tagged` b WHERE a.fk_aid = b.fk_aid AND ((b.fk_tid=3) AND a.fk_tid=13)  
              
              

              Hat jemand Erfahrungen damit und weißß wie sich das ganze mit n Möglichen SELF-Joins verhält?

              Gruß,
              Severin

              --
              They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.
              -- Benjamin Franklin
              1. yo,

                Hat jemand Erfahrungen damit und weißß wie sich das ganze mit n Möglichen SELF-Joins verhält?

                wie Vinzenz bereits sagte, so sind deine Selfjoins nur eine lösung, wenn du die tiefe kennst. da du aber beliebig tief verschachteln kannst, wirst du es nicht mit self joines lösen können. um die rekursion auflösen zu können braucht es programmlogik oder aber ein dbms wie oracle.

                rekursionen ind relationalen dbms sind nicht trivial und können diverse probleme bereiten.

                Ilja