ma ne frage ich hab eine tabelle:



CREATE TABLE `keyword_matches` (
`img_id` mediumint(6) unsigned NOT NULL default '0',
`key_id` mediumint(7) unsigned NOT NULL default '0',
KEY `img_id` (`img_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;


INSERT INTO `keyword_matches` (`img_id`, `key_id`) VALUES
(321003, 14),
(321003, 6),
(321003, 13),
(321003, 4),

(321004, 7),
(321004, 6),
(321004, 14),
(321004, 4);


.....



jetzt möcht ich aus der tabelle alle datensätze haben die eine key_id von 14 aber nicht von 13 haben also im falle oben nur img_id 321004. igendiwie tue ich mir am ansatz schwer weil logischer weise ein query wie key_id = 14 AND key_id != 13 ja quatsch is. meine idee war so was in die richtung:


Select DISTINCT * FROM keyword_matches AS tbl1 INNER JOIN (SELECT * FROM `keyword_matches` where key_id != 13) AS tbl2 USING(key_id) WHERE tbl1.key_id = 14


da stürzt mir immer der server ab ;) mit anderen worten ich hab mich verlafen - was ist der beste ansatz ein tip würde helfen ...

danke

f*

SELECT * FROM keyword_matches
WHERE key_id=14 AND COMPLETELY_REDUNDANTLY key_id!=13

wenn man die Frage liest, kommt man auf obiges, aber das ist nicht gemeint....

? ja ist mir schon klar das die tabelle für diese art der suche nicht geschaffen ist ... aber es muss auch so gehen - keiner eine idee?

SELECT * FROM keyword_matches WHERE key_id = 14 AND img_id NOT IN (
SELECT img_id FROM keyword_matches WHERE key_id = 13
)

aber der Query ist natürlich unglaublich aufwendig
id select_type table type possible_keys key key_len ref rows Extra
1 PRIMARY keyword_matches ALL NULL NULL NULL NULL 8 Using where
2 DEPENDENT SUBQUERY keyword_matches index_subquery img_id img_id 3 func 2 Using index; Using where

sobald da viel mehr Datensätze rein kommen, solltest du den nicht mehr bei jedem Skriptaufruf absetzen...

wie ist folgende Idee:
select * from keyword_matches as a where a.key_id=14
left join keyword_matches as b
on b.key_id=13 and a.image_id=b.image_id
where b.key_id= NULL

und nun korrekt(er):
select a.* from keyword_matches as a
left join keyword_matches as b
on b.key_id=13 and a.image_id=b.image_id
where b.key_id IS NULL and a.key_id=14

dh ein (LEFT) JOIN: linke Tabelle alle mit key_id=14, rechts alle mit key_id=13 .

PS kann man eigentlich der ersten Tabelle auch eine JOIN-Bedingung geben, dh.
SELECT a.* from konstant
INNER JOIN keyword_matches a on a.key_id=14
LEFT JOIN keyword_matches b on b.key_id=13
and a.image_id=b.image_id
WHERE b.key_id IS NULL

[edit dummer Fehler geändert]

PS vielleicht sowas?:
SELECT a.*
FROM (select '1') as k
INNER JOIN keyword_matches a on a.key_id=14
LEFT JOIN keyword_matches b on b.key_id=13
and a.image_id=b.image_id
WHERE b.key_id IS NULL

@ghostgambler sowas hatte ich auch schon mal und war verdutz das es nicht klappte? bei dem sample dump fkt es aber in der richtigen tabelle mit 42.000 datensätzen fkt es nicht - da krieg ich immer null zeilen raus? auch deine @nix_wie_weg fkt im sample dump aber nicht mehr in der eigentlichen tabelle. ich such noch nach dem grund bin aber noch nicht wirklich weit gekommen ... woran könnte das liegen?
:dontknow:

Original geschrieben von frank7l7
[Bauch deine @nix_wie_weg fkt im sample dump aber nicht mehr in der eigentlichen tabelle. [/B]

keine ahnung. Dann war in der produktiven Tabelle etwas anders als in der Testtabelle, aber nicht nur die Datenmenge.

Vielleicht braucht es einen Index für id_image? das wundert mich sowieso, dass es keinen hat. bzw. umgekehrt für key_id hat es entgegen der Bezeichnung keinen Index.

ne also der dump ist gleich nur das ich einen kleine auschnitt der vlaues genommen habe ausserdem hat die image_id einen index ... oh man .... :confused:



anscheined hängt es daran die IN Funktion nicht so viele parameter haben darf

aber key_id ist kein key, hat keynen Index.

ja ist ein index! ... das problem ist die IN Funktion die akzeptiert nicht soviele parameter ... :(

in der join-Variante (c) by mich hat es kein IN.

und key_id ist gemäss dump kein Schlüssel für diese Tabelle, dafür gibt es keinen Index.

das stimmt hab ich gemacht jetzt haben beide spalten einen index bzw ich probier es in allen kombination aber das ändert auch nichts

die join-variante ist ganz gewöhnlich und sollte eigentlich gehen.
Wie sieht dein sql für die join-Variante in Wirklichkeit aus?

PSPSPSPS bitte berücksichtige, dass ich image_id schrieb, aber es ist img_id....
verwechsle nicht einen mysql_fehler mit einem geht_nicht_fehler

Das von

SELECT * FROM keyword_matches WHERE key_id = 14 AND img_id NOT IN (
SELECT img_id FROM keyword_matches WHERE key_id = 13
)

kann man so schreiben

SELECT * FROM keyword_matches X WHERE key_id = 14 AND img_id NOT IN (
SELECT img_id FROM keyword_matches Y WHERE key_id = 13 and X.img_id=Y.img_id
)

denn alle anderen img_id braucht es sowieso nicht.
Die Liste für IN hat dann entweder 1 Element oder keines.
Dann ist es noch eine Frage der Formulierungskunst, ob NOT IN auf eine
leere Liste wahr oder falsch ist im benötigten Sinne.

edit, wenn die Liste leer ist, gibt NOT IN: wahr.
analog dazu, wenn die Liste leer ist, gibt IN: falsch.

aaaalssso, guck mal im anhang bitte, das ist die original tabelle ... damit wir vom gleichen reden. danke das du dich so bemühst ... ich weiss das sehr zu schätzen. ich komme da auf keinen grünen zweig mit ...

muss jetzt ma grad nachhause, bin in 30 mins wieder online

Mein LEFT JOIN funktioniert. Das Problem besteht darin, dass es img_id mit dem Kriterum key_id=14, aber ohne key_id 13 in deinen Daten nicht gibt. Es haben alle key_id 14 und key_id 13 zusammen.

zb key_id 14 aber ohne key_id 10 geht.

Die anderen queries probiere ich aus und editiere diesen Post.

[edit ergänzung]
die query von ghostgambler mit NOT IN geht.
die query von mir mit NOT IN geht auch.
Sogar die query von mir: SELECT a.* FROM (select '1') as k.... geht .


Was war also los, dass bei op nichts ging??

[tests]
ich habe bei einem Eintrag 13 in eine 23 geändert, und dann getestet:
14 ohne 12 -> keine
14 ohne 13 -> einer
14 ohne 10 -> viele

46 ohne 10 -> viele
46 ohne 45 -> einige weniger.

[edit for clarity]
Damit es sich recht versteht, das ist alles mit einem php-Skript , nicht in PMA, und alle vier query-Arten geben dasselbe richtige bzw. plausible.

Original geschrieben von frank7l7
muss jetzt ma grad nachhause, bin in 30 mins wieder online die 30 Minuten sind jetzt vorbei, sogar c.t.

hola, sorry ich habe gestern spontan besuch bekommen, ... ich bin grad dabei die sachen zu testen ...

so, ... also ich hab mal einiges durchgespielt mir die performance verglichen und die limitierungen erkannt. it ist zwar immer noch ein rätsel warum die abfragen pma keine ergebnisse brachten im php script aber schon? anyway ich werd heute später wenn es hier etwas ruhiger ist noch weiter testen und gucken wo es noch mittel und wege gibt um die abfrage schneller zu machen. danke soweit wie kann ich dir jemals danken für deine einsatz :rocks:

Die Abfragen waren alle gleich schnell, bzw. sofort. Ich habe keinerlei Verzögerung gemerkt.

Es ist interessant, aber auf den ersten Blick nicht glaubhaft, dass es im PMA nicht geht. Das werde ich noch versuchen.

Alle vier Abfragetypen funktionieren in PMA (phpMyAdmin).

die letzte hat, wenn man FROM (select \'1\') AS k schreibt, einen Hänger gehabt, bzw. dauerte lange. Mit FROM (select '1') AS k war alles normal. Es kann sein, dass diese letzte, vierte Abfrage die langsamste in phpMyAdmin ist.