Dotaz: složitější dotaz ze 2 tabulek

[Jakub]

Přílohy:

• produkty.png (5533 bytů)
• parametry.png (8015 bytů)

zdarvím.

Mám tabulku produkty a produkt_parametry - viz příloha.

Do tabulky produk_parametry, se ukládají jednotlivé parametry produktů - každý produkt jich může mít několik. Jde mi to to, jak vypíši produkty, u kterých platí np. tyto podmínky:

parametr_id=8 musí být 'cervena' parametr_id=10 musí být 'zluta'

??

Mohli byste mi prosím ještě poradit, nějakou aktuální knížku o MYSQL - která by se věnovala začátkům až po pokročilé věci?

Děkuji.

Odpovědi

[Ondřej Kopka]

Možná by to šlo takto:

select
   p.*
from
   produkty p
inner join produkt_parametry pp
   on p.id = pp.produkt_id
where
   (pp.parametr_id = 8 and pp.parametr_vlastnost = 'cervena')
   or (pp.parametr_id = 10 and pp.parametr_vlastnost = 'zluta')

Pokud ne, tak bych zkusil z db vytáhnout záznamy pro každou podmínku zvlášť a unionem výsledky spojit dohromady.

[Ondřej Kopka]

Když se na to tak dívám, možná jsem dotaz špatně pochopil. Pokud chceš získat id produktů, které splňují obě podmínky zárověň, napadá mě toto:

select
   *
from
  produkty
where
  id in (select produkt_id from produkt_parametry where parametr_id = 8 and parametr_vlastnost = 'cervena')
  and id in (select produkt_id from produkt_parametry where parametr_id = 10 and parametr_vlastnost = 'zluta')

Psal jsem to z hlavy, asi by se našlo i nějaké elegantnější řešení.

[frEon]

nevyhodou vnerenych selectu je, ze tak (alespon u mysql) vyradis z cinnosti query cache, coz je skoda.

[Filip Jirsák]

SELECT produkty.*
FROM produkty, produkt_parametry AS p1, produkt_parametry AS p2
WHERE produkty.id = p1.produkt_id AND produkty.id = p2.produkt_id AND
  p1.parametr_id = 8 AND p1.parametr_vlastnost = 'cervena' AND
  p2.parametr_id = 10 AND p2.parametr_vlastnost = 'zluta'

[Jakub]

Mockrát děkuji za odpovědi. Zítra to vyzkouším.

Neměli byste ještě tip, na nějakou knihu o MYSQL (jak jsem se zmiňoval v 1. příspěvku)?

[pht]

Neměli byste ještě tip, na nějakou knihu o MYSQL (jak jsem se zmiňoval v 1. příspěvku)?

Např. MySQL Cookbook

[Michal Kubeček]

Vypadá to, že MySQL-isté se tradičně vyhýbají joinům ( :-) ), takže

  select ... from PRODUKTY P
    inner join PRODUKT_PARAMETRY P1 on P1.PRODUKT_ID=P.ID and P1.PARAMETR_ID=8 and P1.PARAMETR_VLASTNOST='cervena'
    inner join PRODUKT_PARAMETRY P2 on P2.PRODUKT_ID=P.ID and P2.PARAMETR_ID=10 and P2.PARAMETR_VLASTNOST='cervena'

(za předpokladu, že (PRODUKT_ID,PARAMETR_ID) v tabulce PRODUKT_PARAMETRY je unique).

Mimochodem, k čemu je v tabulce PRODUKT_PARAMETRY sloupec ID?

[Michal Kubeček]

V tom druhém joinu má být na konci 'zluta'.

[Jakub]

V eshopu to nabídne zákazníkovi třídění. Mám ještě jednu tabulku parametry, kde třeba parametr_id='10' je Barva produku.

Z tabulky PRODUKT_PARAMETRY pak vypisuji hodnoty do < select > a právě to ID používám jako hodnotu...

[Jakub]

< option value="ID">červená< option >

[Michal Kubeček]

Na to stačí PARAMETR_ID.

[Jakub]

to mne nenapadlo. Děkuji

[Toman]

To ID v tabulce přeci potřebuje, jak pak prováže produkty a jejich parametry?

[Michal Kubeček]

Na to nepotřebuje ID v tabulce parametrů:

alter table PRODUKT_PARAMETRY
  add foreign key (PRODUKT_ID) references PRODUKTY(ID)

[Toman]

Tak to pak OK.

[Šangala]

vyhýbají joinům - já právě naopak :)
Není špatné přidat nějaký ten znak navíc, myslím znak `, zvláště začáteční si tak předejde problémům.

SELECT ...`slúpec`... FROM `produkty` AS `p`
    INNER JOIN `produkt_parametry` AS `p1` ON `p1`.`produkt_id`=`p`.`id` AND `p1`.`parametr_id`=8 AND `p1`.`parametr_vlastnost`='cerevena'
    INNER JOIN `produkt_parametry` AS `p2` ON `p2`.`produkt_id`=`p`.`id` AND `p2`.`parametr_id`=10 AND `p2`.`parametr_vlastnost`='zluta'

[Michal Kubeček]

Ty mraky obrácených apostrofů vídám u MySQL-istů často, ale pořád nerozumím, k čemu to má být dobré. Tedy kromě toho, že se tak dotaz stane nepřenositelným a nepřehledným.

[Šangala]

Předpokládám, že víte co to syntakticky znamená, tak jen k čemu je to dobré:

• nemůže dojít ke konfliktu klíčových slov a názvů tabulek či sloupců (což je vhodné pro začátečníka, v diskuzi najdete případy kdy se tyto případy řeší :)).
• řetězec mezi `` je vždy vyhodnocen „jen“ jako název tabulky či sloupce takže je to o stupínek bezpečnější pokud je dotaz skládaný (neříkám že je to odolné vůči sqlinjection, ale může, jen přidanou kontrolou na obsah znaku `, a taky neříkám že to má nahradit jiné techniky)

Co se přenositelnosti týče, ta je stejně přímo aplikovatelná jen ve velmi malé množině příkazů, a zajišťovat ji pouze „normovanými“ dotazy asi není to pravé ořechové…
PS: v postgresql to dáváte za mezi " (když chcete) a čistě osobně si myslím, že to není špatné mít to odděleno od řetězce :)

[Michal Kubeček]

Escapované identifikátory jsou sice možné i jinde (PostgreSQL, Firebird, …), ale nikde jinde než u lidí používajících MySQL jsem se zatím nesetkal s módou znepřehledňovat dotazy escapováním všech identifikátorů "jen tak co kdyby", přestože u drtivé většiny to není potřeba (většinou u žádného). Osobně si myslím, že by si měl člověk dvakrát rozmyslet, než vůbec použije identifikátor, který by bylo nutné escapovat, a zatím jsem se tomu pokaždé bez problémů vyhnul.

[Šangala]

Pokud ovšem víte, že s takovým názvem to nejde, nebo je to klíčové slovo…, anebo vždy nejste ten, kdo do toho má co mluvit a musíte to jen používat… (a nebo taky prostě 'key' se vám může jevit jako nejlepší pojmenování sloupečku :))
Pro přenos dotazů mezi DB engine to může mít svou výhodu, každý engine má jiná rezervovaná slova atd. a záměna nějakého znaku za jiný je lehce proveditelná.
Co se čitelnosti týče - mě to přijde čitelnější:)
Nechci Vám to nějak nutit, ale má to i své výhody :), a však je nepoužívejte… :), každý má možnost si to zvážit sám.

[kuka]

Toto jsem zatim vzdy videl jen u kodu generovaneho nejakym nastrojem. Ze by to nekdo psal dobrovolne, to mi opravdu hlava nebere. A navic to jeste doporucovat zacatecnikum... Ja bych jim naopak doporucil se takovym postupum oklikou vyhybat - citelnost je nejucinejsi zbrani proti chybam bez ohledu na uroven zkusenosti.

[okbob]

Tady jde asi o zvyk. Jak je vidět z diskuze, tak nejen mně eskejpování nepřijde jako dobrý nápad. S tou čitelností je to subjektivní a navíc v ten okamžik jsou identifikátory case sensitive - Takže pak se řeší jiné problémy typu - tabulka Users existuje, ale SELECT * FROM users hlásí chybu.

V případě MySQL má eskejpování možná ještě hlubší smysl a to smazání rozdílu mezi win a linuxem, kdy na Linuxu jsou identifikátory case sensitive a ve win case insensitive.

[Toman]

Je to dobré právě proto, že když mám pojmenovaný atribut/sloupec v tabulce jako order, tak by to asi neprošlo, ale jako `order` nebude problém.

[Michal Kubeček]

A nebylo by lepší nekomplikovat zbytečně život sobě ani dalším, kdo to někdy v budoucnu budou muset spravovat, a nepoužívat identifikátory kolidující s klíčovými slovy?

[Toman]

To nepochybně ano, ale právě order je toho příkladem. Nelíbí se mi atribut s názvem position.

[Tarmaq]

a co pouzit napr. order_?

[Šangala]

Ale fuj :)

[Tarmaq]

proc? mne jako vetsi fuj teda prijde `order`

[Šangala]

No to je jasné, když jste to napsal. Ono je asi zbytečné o tom debatovat - chtěl jsem jen vyjádřit svůj názor :).
Mně v zásadě MySql znak ` vyhovuje a rád jej používám, takže kdo jej nemá rád tak je jasné, že k tomu přistupuje jinak.
'Order' se mi moc také nelíbí jako název sloupce, ale proč ne…

[Tarmaq]

tak jasne, kazdemu vyhovuje neco, me by teda pri psani dotazu dost stvalo porad psat backticky, nehlede na to ze to IMHO zhorsuje citelnost takoveho dotazu, navic to neni prenositelne jak jiz bylo v teto diskuzi zmineno(v MSSQL se misto toho pouzivaji hranate zavorky)

[Šangala]

K té přenositelnosti, je to nejpřenostitelnější :), ve smyslu toho, že tento znak se obvykle nikde nevyskytuje na rozdíl od "" či [], takže jednoduchá záměna, pokud jinak dotazy používají průnik vlastností SQL engine-ů, za patřiční znak a je to přenesené bez ohledu na klíčová slova libovolného z engine-ů.
Již jsem to tak praktikoval, (jen) úložný systém MySQL nebo PostgreSQL nebo M$SQL, dotazy sesmolím v MySQL (na přidání LIMIT mám funkci v provider-u a v M$SQL, pokud se neudělá optimalizace SQL dotazu, je to vyřešeno aplikačně - pokud TOP nestačí).

[Toman]

Pokud použijete např. databázový layer dibi, tak ten vyřeší hranaté závorky a backsticky za vás.

[Tarmaq]

nevyresi, protoze do db nepristupuju jen pres php, ale take pres ruzne utilitky typu psql, PL/SQL Developer nebo MSSQL Management Studio