Multiple Kriterien für 1 Spalte?

[Thomas]

Hallo,

ich habe folg. Problem: Eine Tabelle enthält 2 Spalten. Eine den Frendschlüssel auf Nutzernamen, und die andere Ident-Nummern für Interessen.

Sieht etwa so aus

keyID   intID
1        2
1        3
2        2
3        3
4        2
4        3

Nun sollen alle keyIDs ermittelt werden, die sowohl als intID 2 als auch 3 haben (also keyID 1 und 4).
Ein klassisches
SELECT keyID FROM tab1 WHERE (intID like '2') and (intID like '3')
versagt genauso wie
SELECT keyID FROM tab1 GROUP BY keyID HAVING ((intID='2' AND intID ='3'))

Natürlich kann es auch mal passieren, dass intID 2,5,7,10,40 gesucht sind.

Hat jemand eine Idee/Hilfe?

Danke

Thomas

[Klaus Mock]

SELECT keyID FROM tab1 WHERE (intID like '2') and (intID like '3')

Warum muß es eigentlich immer LIKE sein?
Und warum muß es immer eine Stringkonvertierung sein?
Entschuldige bitte, wenn ich vielleicht den Falschen erwische, aber das kommt hier im Forum so oft vor, daß ich schon annehme, daß es System hat. Was ist an intID = 3 so verkehrt.

versagt genauso wie

Es versagt, weil es unmöglich ist, Datensätze zu finden, bei denen ein und das selbe Feld den Wert 2 _und_ 3 haben kann.
Aber Du kannst Datensätze finden, bei denen das Feld den Wert 2 _oder_ 3 hat.

Natürlich kann es auch mal passieren, dass intID 2,5,7,10,40 gesucht sind.

Da Du nicht gesagt hast, welche Datenbank Du verwendest, schließe ich aus, daß es eine ist, bei der

SELECT foo,bar FROM bla WHERE blub IN (2,5,7,10,40)

funktionieren würde, wie z.B. die, die sich gerade im Webumfeld einer großen Beliebtheit erfreut;-)

Also bleibt Dir nichts anders übrig, als daß Du eine Aneinanderreihung der einzelnen Bedingungen vornimmst.

Grüße
  Klaus

PS: Abfragen wie diese sind IMHO übrigens der einzige Grund, warum es in SQL das Schlüsselwort DISTINCT gibt.

[Thomas]

Hallo,

SELECT keyID FROM tab1 WHERE (intID like '2') and (intID like '3')
Warum muß es eigentlich immer LIKE sein?
Und warum muß es immer eine Stringkonvertierung sein?
Entschuldige bitte, wenn ich vielleicht den Falschen erwische, aber das kommt hier im Forum so oft vor, daß ich schon annehme, daß es System hat. Was ist an intID = 3 so verkehrt.

Normalerweise nichts. Das Beispiel war etwas vereinfacht - die "echten" Werte sind solche netten Konstrukte wie '5.1' oder '9.1.9'. Das war nicht meine Idee, ich muss nur auf die DB noch was zusätzlich aufsetzen. Umstrukturieren ist damit nicht drin :-(

versagt genauso wie

Es versagt, weil es unmöglich ist, Datensätze zu finden, bei denen ein und das selbe Feld den Wert 2 _und_ 3 haben kann.
Aber Du kannst Datensätze finden, bei denen das Feld den Wert 2 _oder_ 3 hat.

OK, schwarz auf weiß ist das doch mal ein Wort. Es war an sich schon etwas unwahrscheinlich, aber man weiß ja manchmal nie.

Natürlich kann es auch mal passieren, dass intID 2,5,7,10,40 gesucht sind.

Da Du nicht gesagt hast, welche Datenbank Du verwendest, schließe ich aus, daß es eine ist, bei der
SELECT foo,bar FROM bla WHERE blub IN (2,5,7,10,40)

» funktionieren würde, wie z.B. die, die sich gerade im Webumfeld einer großen Beliebtheit erfreut;-)

Fast ;-) Noch ist es ein Access-Teil, bald aber MySQL.

Also bleibt Dir nichts anders übrig, als daß Du eine Aneinanderreihung der einzelnen Bedingungen vornimmst.

Naja, und das kostet enorme Server-Zeit. Daher hoffte ich ja auf eine bessere Lösung, die mir entgangen war...

PS: Abfragen wie diese sind IMHO übrigens der einzige Grund, warum es in SQL das Schlüsselwort DISTINCT gibt.

Jepp.

So, dann bastel ich mal das Ding etwas um.

Danke & Gruß

Thomas

[Michael Schröpl]

Hi Thomas,

Also bleibt Dir nichts anders übrig, als daß Du eine
Aneinanderreihung der einzelnen Bedingungen vornimmst.
Naja, und das kostet enorme Server-Zeit.

dann machst Du etwas verkehrt. ;-)

Liegt denn ein Index auf der Spalte, über welche Deine WHERE-Klausel
läuft? (Oder kann M$-Access etwa keine Indexe!?)

Viele Grüße
      Michael

[Klaus Mock]

Hallo,

Fast ;-) Noch ist es ein Access-Teil, bald aber MySQL.

Wenn Access IN(..) nur verstehen würde *seufz* ... ach, das geht ja:-)

Also bleibt Dir nichts anders übrig, als daß Du eine Aneinanderreihung der einzelnen Bedingungen vornimmst.

Naja, und das kostet enorme Server-Zeit. Daher hoffte ich ja auf eine bessere Lösung, die mir entgangen war...

Egal, welche Lösung Du letztendlich benutzt, an sinnvollem Einsatz von Indizes kommst Du nicht herum, wenn Du die Performance verbessern willst.

Grüße
  Klaus