Verhalten von "IN" in WHERE klausel / LEFT JOIN auch bei NULL ?

[Ilja]

yo,

ich habe da 2 bescheidene Fragen.

ich habe drei gezählt...

Ich persönlich denke aber das MySQL das so optimiert das die Klausel das gleiche ist als würde man "WHERE abc = 1 OR abc = 5 OR abc = 8" schreiben.

der IN Operator ist eine sehr bequeme kurzschreibweise einer logischen ODER operation. allerdings hat es noch einen kleinen sehr schönen nebeneffekt, es lößt die klammerproblematik, die bei der explizieten notation mit OR enstehen kann, wenn man auch das logische AND in der WHERE klausel verwendet. nicht vergssen AND bindet stärker als OR. insofern ließt sich IN nicht nur einfacher, es ist auch nicht so fehleranfällig.

Kurz gesagt, geht er bei "IN" direkt auf die Index Schlüssel oder lädt er doch die ganze Tabelle ?

bedinkt kann hier nur die antwort sein. wie eine SQL statement ausgeführt wird, das hängt von vielen faktoren ab, unter anderem auch welche inhalte die tabelle hat, wieiele datensätze in verhältnis dazu in die ergebnismenge kommen, welche version du erwendest, etc. was letztlich hilft ist ein blick auf den ausführungsplan. dort zeigt dir das dbms an, wie es gedenkt das  sql auszuführen.

Meine 2te frage. Wenn ich "abc IN (1,5,7,5)" mache, wir der 2te "5" unterschlagen bei der Ausgabe, wie kann ich es machen das trotz doppelter Einträge bei der Ausgabe wirklich alle ausgegeben werden ?

unterschlagen würde ich jetzt nicht sagen, aber letztlich macht es für das ergebnis keinen unterschied, ob die zweite 5 nun drinne steht oder nicht. es könnte aber eventuell den oben genannten ausführungsplan beeinflussen, vielleicht aber auch nicht. auch hier gilt, ausführungsplan anschauen. für das ergebnis ist es aber letztlich egal.

Wie ihr seht ist da schon mal 4x join auf 1ne Tabelle. Das lässt sich so erklären das tabele 1 4 Felder hat welche ID's zu "erweiterungen" enthalten. Und Ich brauche in der Abfrage halt alle Namen der Erweiterungen. Sodas das Auto dann z.b. "VW Max Power GT3" heißt weil Max, Power und GT3 sind in dem Fall 3 Erweiterungen.

die abfrage so wie sie jetzt ist kann so nicht funktionieren, da du spalten von den tabellen in der WHERE klausel benutzt, die über einen OUTER JOIN mit der ersten tabelle verbunden werden. das ergebnis wäre die gleiche menge, als wenn du einen INNER JOIN verwenden würdest. damit bedingungen in einem OUTER JOIN auch greifen, wenn sie nicht erfüllt sind, dazu müssen alle bedinungen nach der jeweiligen ON klausel stehen.

zum anderen musst du die tabelle nicht 4 mal aufführen, einmal würde reichen und dann in der ON klausel (wie gesagt nicht in der WHERE klausel) die verschiedenen fremdschlüssel mit dem logischen OR operator einbindest. Auch die LIKE Operation würde dort hin gehören.

zum anderen wirft die abfrage die frage nach dem daten-design auf. ich sage ganz bewußt nicht, dass es falsch ist, das kann man nicht ohne die jeweiligen umgebung zu kennen. aber sie wirft fragen auf. und da du ganz explizit nach einem anderen daten-design gefragt hast. und ja auf den ersten blick würde ich es anders machen. du könntest eine tabelle für alle möglichen erweiterungen machen, hast demzufolge also nur noch einen fremdschlüssel. dann brauchst du nur einen einfachen INNER JOIN der tabellen und könntest alle erweiterungen die es gibt mit der GROUP_CONCAT aggregatfunktion zusammenfassen. aber wie das daten-design genau aussehen sollte, das kann man nur genau sagen, wenn man deine umgebung genau kennt.

Ilja