Ich habe eine Tabelle wie folgt:
%Vor%Und ich habe diese Frage:
%Vor% Hinweis: Immer ist das Ergebnis entweder eine Zeile oder null Zeile. (Token-Spalte ist unique )
Wenn es eine übereinstimmende Zeile gibt, ok, alles in Ordnung, aber wenn es keine übereinstimmende Zeile gibt, möchte ich verstehen warum?
user_id existiert aber token nicht token existiert aber user_id nicht Wie kann ich den Grund für "keine Zeile ausgewählt (abgestimmt)" ermitteln?
EDIT: Hier sind alle möglichen Ausgaben:
user_id = :id false ist
token = :token false ist
user_id = :id als auch token = :token false sind
user_id = :id und token = :token true sind, aber nicht in derselben Zeile. Dies gibt immer eine Zeile zurück. 1 für Übereinstimmungen, wenn eine Übereinstimmung vorhanden ist, sonst 0. Es zeigt auch an, ob die Benutzer-ID oder das Token in der Cookie-Tabelle existiert. Mit dieser Methode können Sie feststellen, warum die Where-Klausel fehlgeschlagen ist.
%Vor%VORWORT: Dieses Problem, trotz meiner Abneigung gegen MySQL , war ein ziemlich schwieriges Rätsel, das es zu lösen galt. Keine Verwendung eines FULL OUTER JOINs machte es noch schwieriger. Selbst die "Lösung", die ich anfangs gab, war für die Aufgabe nicht ausreichend.
OUTER JOINS verhalten sich in einem bestimmten Muster, und es war wichtig, jede innere Anfrage als unabhängig von der äußeren gegenüberliegenden Seite als explizite Richtung zu betrachten.
%Vor%Diese Abfrage erzeugt nur Ergebnisse, wenn TableA etwas mit TableB zu tun hat. Da jede verschachtelte Abfrage logisch die gleiche wie oben ist, hat mich selbst das Hinzufügen einer Dummy-Tabelle nur das Ergebnis aus der Dummy-Tabelle hinterlassen und ich fühle mich wie ein ... Dummy .
Während einige intelligente Benutzer UNION / UNION ALL versucht haben, dies zu lösen, ist diese Antwort unzuverlässig und tatsächlich fehlgeschlagen, als ich versuchte, dieselbe Tabelle zweimal zu verwenden.
Der Trick ist es zu garantieren, dass die Ergebnisse immer zurückkehren.
%Vor%On 1 = 1 . Das garantiert, dass die Ergebnisse von beiden Seiten zurückkehren und wir sicherstellen, dass diese Tabellen nur die genauen Informationen abrufen, die wir haben wollten, Bingo! Wir bekommen eine schöne Lösung, die funktioniert, egal ob eine oder beide Seiten NULL sind. BEIM URSPRÜNGLICHEN VERFAHREN AUFPRÜFEN
TABELLENERKLÄRUNGEN :
%Vor% - Meine MySQL Workbench fehlen am Anfang, aus irgendeinem Grund bleiben die Variablen über die Transaktion hinaus bestehen.
VORGEHENSWEISE LÖSUNG
%Vor%Beachten Sie, dass dies in T-SQL funktioniert und in MySQL vor dem Ausführen von PROCEDURE funktioniert. Aus irgendeinem Grund habe ich einen Fehler, bei dem die zweite Variable in meinem Proc während der Abfrage ihren Wert verliert ... selbst wenn ich vor der Abfrage in der Prozedur explizit denselben Wert anrufe.
%Vor%Es gibt keinen Weg (den ich zumindest kenne), um diese Art von Informationen aus nur einer Abfrage wie der hier zu bekommen. Ihre Datenbank führt die Abfrage einfach mit den von Ihnen angegebenen kombinierten Kriterien aus und kommt zu dem Schluss, dass diese Kriterien entweder mit den Zeilen übereinstimmen oder nicht. Es wird sich nicht darum kümmern, mit welchem Ihrer Kriterien es übereinstimmt oder nicht mit Zeilen übereinstimmt.
Angenommen, Sie verwenden diese Abfragen als Teil einer serverseitigen Seitenlogik (wie eine PHP-Datei), würde ich sagen, dass mindestens drei Abfragen das sind, in dem Sie dies tun können.
Die bereits vorhandene Abfrage, die nur dann eine Zeile zurückgibt, wenn eine Übereinstimmung zwischen dem Token und der Benutzer-ID besteht, die Sie suchen.
Eine Abfrage, um die Anzahl der Zeilen zurückzugeben, die mit dem Token übereinstimmen.
Eine Abfrage, um die Anzahl der Zeilen zurückzugeben, die der Benutzer-ID entsprechen.
Wenn Abfrage Nr. 1 eine Zeile zurückgibt, werden die letzten beiden natürlich nicht benötigt: Option # 1 ist erfüllt, weiter zum folgenden Code. Wenn dies nicht der Fall ist, benötigen Sie beide anderen Abfragen, um festzustellen, welche der anderen vier möglichen Optionen den Status der Dinge widerspiegelt:
Wenn Abfrage # 3 mehr als null Zeilen zurückgibt und Abfrage # 2 null Zeilen zurückgibt, ist die Benutzer-ID vorhanden, aber das Token nicht vorhanden - Option # 2 erfüllt.
Wenn Abfrage Nr. 2 mehr als null Zeilen zurückgibt und Abfrage Nr. 3 null Zeilen zurückgibt, existiert das Token, aber die Benutzer-ID stimmt nicht mit Option 3 überein.
Wenn beide Abfragen null Zeilen zurückgeben, ist weder Token noch Benutzer-ID vorhanden - Option # 4 erfüllt.
Wenn beide Abfragen mehr als null Zeilen zurückgeben, sind sowohl Token als auch Benutzer-ID vorhanden, aber da Abfrage Nr. 1 keine Zeilen zurückgegeben hat, sind sie nicht in derselben Zeile vorhanden - Option 5 erfüllt.