Dotaz: MySQL vicenasobny AND nad jednim sloupcem

[mejvas]

Ahoj, mohl by nejaky databazovy specialista poradit s nasledujicim problemem? Snazim se ho vyresit bez uspechu uz druhy den.

Vytvarim dotaz, kdy chci ziskat vypis clanku, ktere jsou pouze ve specifickych kategoriich. Zjednodusene receno

SELECT * FROM `table` WHERE `categ`=X AND `categ`=Y AND `categ`=Z

Problem je, ze MySQL v tomto pripade nic nevrati, i kdyz by mel. Pri googlovani a prohledavani ruznych diskuzi narazim pouze na radu pouzit kontrukci IN tedy `categ` IN (X,Y,Z) Nicmene to neni reseni, protoze konstrukce IN reprezuntuje operator OR nikoliv AND. Tedy vrati i zaznamy, ktere jsou pouze v jedne ze zadanych kategorii.

Vi nekdo jak to resit?

Konkretni pripad. Chci ve wordpressu zobrazit clanky, ktere musi byt ve trech ruznych kategoriich zaroven.

query s pouzitim IN, ktera to neresi SELECT p.* FROM wp_posts AS p JOIN wp_term_relationships AS tr ON p.ID = tr.object_id JOIN wp_term_taxonomy AS tt ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE p.post_status IN ('publish') AND p.post_type IN ('post') AND tt_term_id IN(23,48,52) AND tt.taxonomy IN ('category' , 'post_tag') GROUP BY p.ID ORDER BY p.post_date desc

Budu vdecny za kazde nakopnuti...

---

---

Odpovědi

[kuka]

Ze ten zjednoduseny dotaz nic nevrati je zcela v poradku a je to videt na prvni pohled - tezko se muze nejaka hodnota rovnat zaroven X i Y. Lze pouzit napr. exists ve smyslu existuje zarazeni do kategorie X a zaroven existuje i zarazeni do kategorie Y atd.

[deadmail]

Zavisi od toho ako je ulozene v tej tabulke ... Ak je tam pre jeden clanok patriaci do viacerych kategorii niekolko zaznamov-riadkov (t.j. tabulka clanky_kateg obsahuje dva stlpce (clanok_id, kateg) a zaznamy napr. (clanok5, x), (clanok5, y), (clanok5, z)), tak by mohlo fungovat nieco taketo:

SELECT clanok_id 
FROM (SELECT clanok_id FROM clanky_kateg WHERE kateg="x") AS tbl_x 
JOIN (SELECT clanok_id FROM clanky_kateg WHERE kateg="y") AS tbl_y USING (clanok_id)
JOIN (SELECT clanok_id FROM clanky_kateg WHERE kateg="z") AS tbl_z USING (clanok_id)

[Filip Jirsák]

Tím jste ale jen složitě nahradil IN nebo OR.

[Filip Jirsák]

Eh, pardon, kecám. Viděl jsem tam nevím kde UNION…

[Filip Jirsák]

Pokud to chcete řešit univerzálním parametrizovaným dotazem (tj. nepřidávat tolik JOINů, kolik je kategorií), mělo by to jít udělat tak, že v subselectu načtete všechny kategorie daného článku, které patří do požadovaných kategorií (pomocí IN), a pak porovnáte počet požadovaných kategorií s počtem záznamů tohoto subselectu.

SELECT clanek_id 
FROM clanky
WHERE (
  SELECT COUNT(DISTINCT kategorie_id)
  FROM kategorie
  JOIN clanek_kategorie ...
  WHERE kategorie_nazev IN (?)
) = ?;

V prvním parametru pak bude seznam požadovaných kategorií, v druhém jejich počet.

[l0gik]

Myšlenka dobrá, ale...

V tom subselectu zchází "vazební" podmínka na parent table.

Pokud by tam byla, jde o subselect vázanej na každou řádku, takže je to hrozně pomalý.

Proč DISTINCT kategorie_id? (když už distinct, tj. předpokládám možnost duplicitních kategorií jednoho článku, tak snad kategorie_nazev, ne - kategorie_id bude tak jako tak unikátní)

Přitom by úplně stačilo:

SELECT clanek_id FROM kategorie 
WHERE kategorie_nazev IN (...)
GROUP BY clanek_id
HAVING COUNT(DISCTINCT kategorie_nazev) = ...

Popř. pokud bychom chtěli celej článek, tak to obalit SELECT * FROM clanek WHERE clanek_id IN (..dotaz výše..).

Jinak pokud není výsledkem skoro celá tabulka článků, tak je řešení s JOIN IMHO lepší, protože to umožní využít indexy. Todle IMHO nutně projde všechny články, i když ve výsledku jich bude jen pár a i když by třeba v jedné kategorii žádný článek nebyl.

To, co tady chceme po databázi je vlastně průnik množin. A to je prostě INNER JOIN. Opisovat to jinak sice jde, ale většinou je lepší optimalitzaci nechat na databázi, než ji vnucovat nějakou svoji. Vygenerovat ty inner joiny programovým kódem je triviální. SQL je ukecanej jazyk, krátkej zápis ještě nemusí znamenat, že je optimální.

[Filip Jirsák]

Dotaz na kategorie článku se stejně musí vždy provést, ať už bude mít formu subselectu nebo jinou. Distinct pro případ, že by článek měl jednu kategorii přiřazenou vícekrát. Řešení s GROUP BY má tu nevýhodu, že takhle vytáhnete jen ID článků -- předpokládám, že ve skutečnosti budou potřeba i další údaje, takže by bylo nutné výsledek tohoto dotazu použít v dalším dotazu na ostatní hodnoty.

Souhlasím, že INNER JOINy budou pro databázi průhlednější, ale dotaz je pak závislý na vstupních datech a teoreticky při velkém počtu požadovaných kategorií může být problém s počtem JOINů.

[l0gik]

Jo, jenže závislé subselekty se dělají pro každý řádek zvlášť, zatímco GROUPBY se provede jednou pro všechny. Někdy si pravda databáze závislý subselect zoptimalizuje, ale spoléhat se na to nedá a u dotazu s COUNT obzvlášť ne. Navíc pokud si ten subselect databáze zoptimalizuje, tak právě do formy toho GROUPBY.

Jo, jenže na vyloučení duplicit kategorií je Ti DISCTINCT kategorie_id na nic, protože kategorie_id je PK a tedy unikátní by definition. Na výsledek tedy DISTINCT žádnej vliv nemá. To bys tam musel mít count(DISTINCT kategorie_nazev).... Jak píšu už v předešlym postu.

Tak dáš group by do subselectu a vytáhneš si k tomu zbytek z tabulky článků, vždyť to tam taky píšu. Pořád to ale bude výkonem někde jinde, než spešl selekt pro každou řádku z článků.

Problém s počtem joinů? To by musel bejt jó velkej počet kategorií, aby se to nevyplatilo. Takovýdle dotazy se dělaj většinou ve filtrech se vstupem užíváka, takže to myslím nehrozí.

[Filip Jirsák]

Jo, jenže na vyloučení duplicit kategorií je Ti DISCTINCT kategorie_id na nic, protože kategorie_id je PK a tedy unikátní by definition. Na výsledek tedy DISTINCT žádnej vliv nemá. To bys tam musel mít count(DISTINCT kategorie_nazev)....

DISTINCT neřeší duplicity názvů v tabulce kategorií, ale duplicitu přiřazení kategorií k článkům. Pokud by v mapovací tabulce byly duplicitní záznamy, přes JOIN by se dostaly i do výsledné sady a pak by COUNT neseděl.

clanek_id | kategorie_id
----------+-------------
        1 |            1
        1 |            2
        1 |            2   -- duplicita!
        2 |            3

Lepší řešení je samozřejmě unikátní index na clanek_id+kategorie_id, ale DISTINCT podle mne v tomto případě skoro nic nestojí a ten kód nebyl v žádném případě hotový jen ho zkopírovat a použít, byl myšlen jen jako náčrt, který by si tazatel musel dodělat.

[l0gik]

Jo takhle, ty tam máš join a dvě tabulky, to jsem přehlíd, pak to tak je: tím, žes vypustil ON a v tom distinct nekvalifikoval (což bys s joinem musel) jsem předpkládal, že je to jednodušší a blbější struktura, kdy ve vazební tabulce je rovnou název kategorie, pak by naopak byl potřeba distinct na ten název a ne na id, takhle je to dobře.

Nicméně ostatní výtky, hlavně ta, že dělat pro každou řádku subselect, trvají, todle je jen detail.

[Dejv]

SELECT *
FROM `table`
WHERE `categ`=X
   AND `categ`=Y
   AND `categ`=Z

fungovat nemuze, jak uz bylo vyse zmineno i vysvetleno.

select t.idclanku, t.navezclanku...
from table t
   inner join categ c1 on c1.idclanku=t.idclanku and c1.cat='X'
   inner join categ c2 on c2.idclanku=t.idclanku and c2.cat='Y'
   inner join categ c3 on c3.idclanku=t.idclanku and c3.cat='Z'
where
   t.idclanku=...

sice (asi) neni nejvhodnejsi z hlediska vykonu, ale fungovat by mohlo. Akorat mozna bude potreba zmenit ty joiny ma nejake left nebo right outer.

[l0gik]

INNER JOINY jsou dobře a naopak je to z hlediska výkonu to nejlepší. Protože to nechává optimalizaci na databázi. Pokud bude výsledkem +- celá tabulka, tak si to vybere nejmenší, ostatní zahašuje a tu nejmenší projede. Bude to stát cca N, takže pohoda.

Pokud bude alespoň jedna kategorie malá, tak to IMHO vybere její záznamy a ověří, že jsou i v ostatních kategoriích. Opět nejlepší postup.

Ostatní zde nabízené postupy donutí databázi ke konkrétnímu plánu, což může být někdy ten nejlepší, ale v jiné situaci katastrofa.

[l0gik]

INNER JOINY jsou dobře a naopak je to z hlediska výkonu to nejlepší. Protože to nechává optimalizaci na databázi. Pokud bude výsledkem +- celá tabulka, tak si to vybere nejmenší, ostatní zahašuje a tu nejmenší projede. Bude to stát cca N, takže pohoda, ostatní nabízené postupy na tom nebudou lépe.

Pokud bude alespoň jedna kategorie malá, tak to IMHO vybere její záznamy a ověří, že jsou i v ostatních kategoriích. Opět nejlepší postup.

Ostatní zde nabízené postupy donutí databázi ke konkrétnímu plánu, což sice může být někdy ten nejlepší, ale v jiné situaci katastrofa.

[Semo]

Na denormalizaciu chces pouzit operator GROUP_CONCAT(expr).

Takze asi nieco ako

SELECT clanok_id, ','||group_concat(categ)||',' as allcat
FROM table
GROUP BY clanok_id
HAVING allcat LIKE '%,X,%'
    AND allcat LIKE '%,Y,%'
    AND allcat LIKE '%,Z,%'
;

Pisem to z hlavy a zijem na inej databaze, takze mozno nieco z toho bude treba zapisat v MySQL inak, ale asi by to malo chodit.

[rADOn]

Tohle může krásně fungovat pro pět a půl řádku, ale ne nad většími daty. Efektivně jsi vyřadil možnost použít jakýkoliv index.