Ankündigung

Einklappen
Keine Ankündigung bisher.

Vergleich von 3 Tabellen, Ausgabe von Daten die noch nicht in Tabelle 3 stehen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Vergleich von 3 Tabellen, Ausgabe von Daten die noch nicht in Tabelle 3 stehen

    Hallo,

    ich habe jetzt sehr viel gelesen zu union, Joins etc. - Leider komme ich aktuell an meine Grenze für diese Herausforderung und benötige tatsächlich Hilfe. Vielleicht kann mich jemand unterstützen?!

    Mein Projekt:

    Userportal für Bewertungen von Online-Werbung

    Meine Herausforderung:

    ich habe 3 Tabellen:

    Tabelle 1 = Online Kampagne (c)
    Tabelle 2 = User (u)
    Tabelle 3 = Tracking (t)

    in der Tabelle (u) sind alle Userdaten gespeichert. In dieser Tabelle ist der user_token massgebend.
    in Tabelle (c) befinden sich alle Kampagnendaten für die einzelnen Bewertungen für die User. massgebend hier ist campaign_id.
    Tabelle (t) beinhaltet alle Useraktivitäten zu den einzelnen Kampagnen aus tabelle (c) - hierin wird bei der Action der user_token, action_time und die dazugehörige campaign_id geschrieben.

    Jetzt möchte ich sehr gerne, dass dem User NUR die Kampagnen angezeigt werden, die er noch nicht bewertet hat.

    Als Beispiel:

    Tabelle 2 (u) Inhalt ---> user_token = 123456

    Tabelle 1(c) Inhalt ---> 1.campaign_id = 11111
    2.campaign_id = 22222
    3.campaign_id = 33333

    Tabelle 3(t) Inhalt ---> 1. user_token = 123456, action_time = 03.05.2018, campaign_id = 11111
    2. user_token = 123456, action_time = 14.04.2018, campaign_id = 33333


    Jetzt hat der User mit der user_token = 123456 noch nicht die Kampagne mit der campaign_id = 22222 erledigt und soll nun nicht mehr alle 3 angezeigt bekommen, sondern nur noch die, die er noch nicht gemacht hat, also campaign_id = 22222.

    Wie bewerkstellige ich das am besten mit einer mysqli Abfrage?

    Lieben Dank für jede Hilfe.
    Anke


  • #2
    MOD: Verschoben von PHP-Einsteiger
    The string "()()" is not palindrom but the String "())(" is.

    Debugging: Finde DEINE Fehler selbst! | Gegen Probleme beim E-Mail-Versand | Sicheres Passwort-Hashing | Includes niemals ohne __DIR__
    PHP.de Wissenssammlung | Kein Support per PN

    Kommentar


    • #3
      Da hilft alles nichts, das musst du lernen.
      Die verschiedenen Join Typen.

      Welcher denkst du ist der Richtige?

      Kommentar


      • #4
        protestix Danke Recht hast Du. Ich les mir das noch mal durch. Vielen Dank für den Schups in die Richtung des "dass musst Du lernen" Ich wollte schon aufgeben...

        Kommentar


        • #5
          Zitat von Einsteigen Beitrag anzeigen
          protestix Danke Recht hast Du. Vielen Dank für den Schups in die Richtung des "dass musst Du lernen" Ich wollte schon aufgeben...
          Die Antwort ist richtig, aber wir müssen alle lernen, also ein pragmatischer Vorschlag:
          Lerne es später, probiere es lieber aus. Der Link zeigt 10 Join Typen oder 12? Ich habs nicht gezählt, aber so viele sind es nicht. Ein paar kann man für dieses Problem vielleicht gleich beiseite lassen oder Du kennst sie schon. Also eigentlich echt übersichtlich.

          Du hast ja bestimmt schon passende Daten, also einfach die Beispiele aus dem Link auf Deine Tabelle umschreiben und schauen was rauskommt. Dann kannst Du Dich mit dem Favoritenergebnis beschäftigen.

          Der Punkt ist:
          "Nicht-Mengen" in SQL sind ätzend. Wie joined man Daten, die es nicht gibt?

          Und noch ein Hinweis, "lernen" war nicht der einzige Tipp von protestix, er hat auch noch eine Frage gestellt.

          Kommentar


          • #6
            So, es hat gedauert, da doch einiges dazwischen kam. Ich hab es gepackt Mit LEFT JOIN. Es war hart, aber es hat sich gelohnt. Vielen Dank an Alle.

            Kommentar


            • #7
              Leider sind die Abbildungen im verlinkten Artikel ungünstig gewählt, denn JOINs sind keine Schnittmengen (siehe ausführliche Kritik, z.B. hier: https://blog.jooq.org/2016/07/05/say...laining-joins/). Abgesehen davon bezieht sich der Artikel auf CouchBase anstatt auf etwas klassisch Relationales, MySQL kann beispielsweise gar keinen Full Outer Join.

              Kommentar


              • #8
                Zitat von Tropi Beitrag anzeigen
                Leider sind die Abbildungen im verlinkten Artikel ungünstig gewählt, denn JOINs sind keine Schnittmengen
                Das ist gut beobachtet, aber auch die Kritik bzw. die "bessere" Erklärung im Link finde ich in den Formulierungen und Darstellungen auf andere Weise unglücklich, die ständigen "Cross Joins", auf die angeblich alles aufbaut, und die "Herleitung" von z.B. "Left Joins" oder "Full Joins" sind in (verkürzter) Benennung und Darstellung nicht glücklich. Sind es doch alles vor allem ".. Outer Joins" (egal ob rechts oder links), was ansich keine griffige Bezeichnung aber wenigstens etwas deutlicher ist, gerade den Full Outer Join verkürzt als Full Join zu bezeichen, scheint mir ungünstig, besonders wenn man ansteht, um etwas "viel richtiger" darzustellen. "Full Join" klingt für mich wie der fetteste Join, den man sich vorstellen kann, dabei ist es (fast) das Gegenteil. (Und der Begriff/Befehl selbst nur eine Konzession an die Faulheit, halt eine Abkürzung)
                Für Anfänger sicher auch nicht sehr hilfreich.

                Ich finde, ein paar Beispiele mit Echtdaten (jeweils eine handvoll Datensätze und Tabellen reichen) sagen mehr als 1000 Worte und Bilder. Damit dann vor allem selbst rumspielen. Man kann nichts kaputt machen, man sieht/erlebt die unterschiedlichen Ergebnisse direkt.

                Kommentar


                • #9
                  Zitat von Perry Staltic Beitrag anzeigen
                  gerade den Full Outer Join verkürzt als Full Join zu bezeichen, scheint mir ungünstig,
                  Das steht nirgends in dem Artikel. Außerdem machen sowohl MySQL, Postgresql und vermutlich auch andere das "OUTER" optional in der Syntax.

                  Zitat von Perry Staltic Beitrag anzeigen
                  "Full Join" klingt für mich wie der fetteste Join, den man sich vorstellen kann, dabei ist es (fast) das Gegenteil. (Und der Begriff/Befehl selbst nur eine Konzession an die Faulheit, halt eine Abkürzung)
                  Weiß nicht was du dir vorstellst und was du mit "fettem" Join meinst, aber ein FULL OUTER JOIN bringt, abgesehen von CROSS JOIN, nunmal auch die meisten Ergebniszeilen? So falsch wäre das gar nicht. Abgesehen davon, dass wie oben schon genannt, "full join" nirgends vorkommt.

                  Obwohl ich den Artikel nicht selbst geschrieben habe, sehe ich auch nicht die Ansprüche heraus, die du ihm andichtest. Es ist keine bessere Erklärung (für Anfänger ja auch viel zu kurz), sondern eine Kritik an den Venn-Diagrammen als Erklärungsmittel für Joins. Das ist imho mit dem Titel und der Conclusio mehr als deutlich.

                  Kommentar


                  • #10
                    Zitat von Tropi Beitrag anzeigen
                    Das steht nirgends in dem Artikel. Außerdem machen sowohl MySQL, Postgresql und vermutlich auch andere das "OUTER" optional in der Syntax.
                    Mag sein, ich hab die Buchstaben nicht gescannt. Da der Artikel explizit auf die Diagrammform abhebt -und dabei zu Unrecht alle (Venn)Diagamme in einen Topf wirft- sollte er es besser machen. Gerade aber in seinen Diagrammen nennt der Artikel explizit, textuell als Legende neben dem "Inner Join" -was eine vollständige Bezeichnung ist- alle "Outer" Joinvarianten ohne extakt diesen "Outer" Bestandteil, obwohl er nach meiner persönlichen Vorstellung das Wesen eines solchen Joins, eben das "Outer" (im Kontrast zum "Inner") bestimmt, während "Left","Right" und "Full" eher Varianten wären.

                    Zitat von Tropi Beitrag anzeigen
                    ..was du mit "fettem" Join meinst, aber ein FULL OUTER JOIN bringt, abgesehen von CROSS JOIN, nunmal auch die meisten Ergebniszeilen? So falsch wäre das gar nicht.
                    Es ist natürlich Geschmackssache, wie man diese Begriffe gewichtet. Das "Full" bezieht sich dem Sinn nach auf das "Outer" und nicht auf das JOIN. Es ist demnach variant zu "Left" und "Right" zu verstehen. Die in vielen RDBMS gängige Abkürzung auf "Full Join" verschiebt sprachlich diese Beziehung leider (ins gefühlte Gegenteil), während sind natürlich haargenau die gleiche Join Operation auslöst, wie die korrekte, lange Formulierung. Natürlich ist das -wenn einmal verstanden- kein Problem und auch nicht mein Kritikpunkt an den RDBMS.

                    Zitat von Tropi Beitrag anzeigen
                    Obwohl ich den Artikel nicht selbst geschrieben habe, sehe ich auch nicht die Ansprüche heraus, die du ihm andichtest. Es ist keine bessere Erklärung (für Anfänger ja auch viel zu kurz), sondern eine Kritik an den Venn-Diagrammen als Erklärungsmittel für Joins. Das ist imho mit dem Titel und der Conclusio mehr als deutlich.
                    Nun ja, es geht hier in dem Thread um ein Anfänger Verständnisproblem und wenn Du den Artikel so einordnest, dass er für Anfänger nicht gedacht ist, wieso führst Du ihn hier auf?

                    Meine Anmerkungen wirken vielleicht wie Klagen auf hohem Niveau oder wirken vielleicht sogar unverständlich. Das Problem, dass ich sehe, bezieht sich mehr oder weniger auf die Qualität des verlinkten Artikels und auf die (zu) pauschal kritisierten Venn Diagramme. Während einem geübten Nutzer beide Darstellungen eine gute "Gedächtnisstütze" sein könnten, ist die hier aufgeführte, bunte Mischung für Anfänger einfach keine gute Hilfe. Die Diagramme sind einfach zu ungenau oder zu ungenau/unglücklich beschriftet- und damit teilweise tatsächlich falsch.

                    Ich finde es einfach schade, wenn Ungeübte durch solche populären -aber sagen wir mal etwas schludrigen- "Erklärungen" in die Irre geführt werden. Und nach allem, was ich in derartigen Foren bis jetzt gesehen habe, ist es nicht selten, dass auch Leute jenseits des Anfängerbereichs mit Left Joins & Co schnell mal ins Schleudern kommen.

                    Kommentar

                    Lädt...
                    X