Dotaz: Mysql dotaz

[Ex]

Ahoj,

Chtel bych poprosit o radu se sestavenim sql dotazu.

Zjednodusene rekneme ze jsou dve tabulky:

users (se sloupcem id)

items (se sloupcem user (cizi klic do users) a item)

Potrebuji dotaz, najit usera ktery ma v tabulce items radky s item 1 a zaroven 5.

Diky moc za pomoc

Odpovědi

[kuka]

Napriklad muzes pouzit exists.

[Dejv]

Vykonove asi nic moc, ale fungovat by mohlo (pokud jsem pozadavek spravne pochopil)

select ...
from users u
   inner join items i1 on i1.user=u.id and i.item=1
   inner join items i5 on i1.user=u.id and i.item=5

[Tarmaq]

hh koukam ze jsi byl rychlejsi, navic to mame skoro stejne :] akorat mas spatne aliasy v tom porovnavani na item.. ale to se stane no ;]

[Dejv]

Jo, mam Samozrejme tam ma byt i1 a i5, tak jak to mas ty

[Tarmaq]

SELECT DISTINCT u.id
FROM users u
INNER JOIN items i1 ON i1.user = u.id AND i1.item = 1
INNER JOIN items i5 ON i5.user = u.id AND i5.item = 5

[kuka]

Kazdy distinct je podezrely a tento obzvlast. Bud tam neni potreba (je zaruceno, ze kazdy item je pro uzivatele v items nejvyse jednou), nebo tam potreba je, a pak by se melo misto nej pouzit exists.

[Ex]

Diky za tento napad, bez takoveho nasobneho spojovani to mozne neni? Protoze 2 hodnoty item byl priklad, potreboval bych ji i vice, a pak mi to uz neprijde jako vhodne reseni.

[kuka]

Mozne to je i bez "takoveho nasobneho spojovani". Treba kdybys napsal, co potrebujes, tak by ti nekdo poradil "vhodne" reseni. Toto se ti nelibi proc - kvuli vykonu, kvuli tomu, ze nevis, kolik hodnot bude, nebo treba jen esteticky?

[Ex]

Ano jak rikas, vykonove, myslim si ze pri vice polozkach by to nemuselo byt uplne ono.

[kuka]

No a mas tuto domenku necim podlozenou? Pokud budes chtit vsechny uzivatele s danou vlastnosti, bude pravdepodobne nejvykonnejsi group by dotaz pouze pres tabulku items. Pokud budes chtit jen pro jednoho nebo nekolik uzivatelu overit vlastnost, bude temer jiste nejefektivnejsi opakovane spojeni users s items (primo nebo pres exists), jak zde bylo navrhovano (pochopitelne za predpokladu, ze tam bude vhodny index). Samozrejme zalezi i na poctech zaznamu, pro radove desitky az stovky nebudou nejspis zadne rozdily vubec meritelne. V nekterych pripadech muze byt nejlepsi proceduralni zpracovani mimo databazi, pokud prichazi v uvahu.

[Kit]

Jde to i pro vícenásobné spojování a nemusí to být pomalé. Pokud bys to chtěl bez toho, musel bys opustit model EAV a navrhnout databázi pořádně.

Další možností je použití hstore v PostgreSQL.

[kaaja]

Protože nemám mysql, tak nevím jestli to bude fungovat, ale na jiné db určitě bude

SELECT DISTINCT u.id
FROM users u
where (select count(*) from items i where i.item in (..polozky..)  ) = pocet_polozek

[kuka]

Tak tohle urcite nebude fungovat nikde, napriklad se tam jaksi nevyskytuje zadna podminka na tu tabulku users. Myslenka jako takova je pouzitelna, ovsem spravne realizovana vede na jednoduchy group by dotaz nad items

select user_id from items 
where item in (..polozky..)   
group by user_id 
having count(*) = pocet_polozek

[kaaja]

Sorry, psal jsem to na sucho a vypadlo mi to

SELECT DISTINCT u.id
FROM users u
where (select count(*) from items i where i.item in (..polozky..) and i.user = u.id  ) = pocet_polozek

[George O.]

Mnohem jednodussi bude navrhnout db jako clovek, pak ti bude stacit jednoduchy inner join

[Kit]

Existuje pár typů aplikací, ve kterých to nejde tak jednoduše. Například obchod s komponentami PC. Každý díl může mít jinou sadu parametrů a předělávat databázi s každým novým typem zboží nemusí být levná záležitost. Výhodnější je navrhnout univerzální strukturu, kterou bude moct obchodník pracovat dle potřeby.

[Josef Kufner]

Na tohle sice slouží EAV, ale je jednodušší naučit aplikaci používat ALTER a různé tabulky pro velmi odlišné typy zboží (pak stačí jeden join podle typu). Sice to není zrovna krásné z pohledu relačních databází, ale ušetříš si tím mnoho dní práce a ladění.

Kdysi už tu na tohle téma pár diskusí bylo a tohle jsem tam popisoval podrobněji.

[kuka]

Zda se, ze mas kvalitni kristalovou kouli. Jak tedy bude vypadat tazatelova databaze, kdyz ji navrnes ty pro svuj "jednoduchy inner join"?

[Kit]

Každá vlastnost bude mít vlastní sloupec v nějaké tabulce.

[kuka]

No tak kdybych se pridrzel toho, co nam tazatel sdelil (users, items), tak items by mohly byt klidne treba fasovane veci. Bude velice prakticke, az nejakemu uzivateli koupi novou lampicku, pridavat sloupec to tabulky nebo lepe do vice tabulek. Proste nikdo netusi, k cemu to ma byt, takze odpoved "navrhni si databazi lepe" je nesmyslna. Navic zmena struktury databaze nebyva vhodnym postupem ve vetsine scenaru, napriklad pokud nekdo dostane za ukol udelat report nad existujicimi daty.

[Josef Kufner]

select u.*
from users as u
left join items as i on i.user = u.id
where i.id IN (1, 5)
group by u.id
having count(i.id) = 2

[Kit]

Hmm. A co když bude mít 2× item1 a ani jednou item5?

[kuka]

Bud musi byt vecne zarucena unikatnost nebo

...count(distinct i.id)...

[Josef Kufner]

Na sloupci item.id nejspíš bude primární klíč, takže duplicita nehrozí.

[Kit]

V tom případě se mi víc líbí řešení od Tarmaq.

Tazatel psal, že se počet těch podmínek bude měnit. To znamená, že ten dotaz bude pokaždé vypadat hodně jinak. V původním řešení se jen budou přidávat další řádky.

Kdyby v MySQL bylo možné i scheme-less řešení (např. hstore), tato debata by byla už dávno u konce.

[Josef Kufner]

Otázkou je, co bude rychlejší a jak ty dotazy i data nakonec budou vypadat.

Já bych se ale na EAV a podobné zrůdnosti vykašlal. Pokud jde o filtrování podla tagů nebo něčeho takového, tak ten group by je mnohem rychlejší (pokud si to pamatuju dobře; kdysi jsem právě přepisoval hnusný selecty z jednoho tvaru do druhého, jen už nevím, jak to dopadlo).

[Kit]

EAV je dobře použitelné, pokud je hodně atributů a málo záznamů. Předpokládám, že přesně tohle je případ tazatele. Pokud by tomu bylo jinak, EAV by asi nepoužil.