Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Zelený je lopuch,
fotbal to je hra...

Lopuch.cz
Jméno:
Heslo:
Podpora LCD:
 
Klub Database (mysql,...) [ŽP: neomezená] (kategorie Programování) moderuje melkor_unlimited.
Archiv
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: frnxtcy
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
king King Born to be king - ... 22.2.2012 23:34  1412
Neco takoveho by mohlo fungovat: 

SELECT

  agg.name, agg.price, shares.cnt

FROM

  (

    SELECT

      name, MIN(price) as price

    FROM

      shares

    GROUP BY

      name

  ) as agg

    INNER JOIN shares on (agg.name = shares.name AND agg.price = shares.price)
bredy 22.2.2012 22:45  1411
KingDíky, upravil jsem ten dotaz co jsi postoval ještě trošku jinak, a to tak, že ten join vztah mezi tema tabulkama má navíc podmínku, že tag z levé tabulky musí být menší než tak z pravé tabulky. Má to tu výhodu, že když požaduju víc tágů než položka má, hned se vyřadí, protože prostě jedna z techto podmínek nebude splněna. Pak se WHERE aplikuje na menší množinu výsledků, než by tomu bylo v případě, že tam nedám to omezení. Nevýhodou je, že tágy musím před sestavením dotazu seřadit, ale to dělám v PHP funkcí sort().

Pak nevím, jak udělat v SQL toto:

Mám tabulku akcíí a mám tabulku cen a počtů pro každou akcii 1:N A chci sestavit dotaz, který vytáhne tabulku všech akcíí se nejlevnější nabídkou a počtem akcií pro tuto nabídku.

Napíklad ČEZ - (836,50 - 832, 10 - 834,1000) Výsledek ČEZ,832,10 ... a tohle pro každý titul v jednom dotazu.
king King Born to be king - ... 12.2.2012 10:08  1410
SQL skutecne neni vhodnym nastrojem na efektivni zpracovani takovych dat, jestli muzes mrkni se po necem vhodnejsim, vrele muzu doporucit redis a elastic search - prvni ti da vynikajici nastroje na praci s tagama (mnoziny, server side union, intersect apod), druhy to cele vyresi za tebe kdyz si spravne nadefinujes mapping (~~ schema)
bredy 12.2.2012 00:30  1409
Ještě příklad: big,medium,red,green,fruit
vede na:
(big or medium) and (red or green) and fruit.

Já to právě převáděl na součinový tvar, protože jsem viděl jak to pomocí joinů budu hledat a slučovat. Třeba tě napadne lepší zápis takového query

A ještě něco, když je to disjunktní tak to jde, horší je, že zákazník si u některých tágů přeje početné omezení, například, že nějaká skupina tágu se může u každé položky vystkytnout jen ve třech vydání. Pokud budu tedy hledat čtyři tágy z této skupiny ANDem, nenajdu nic. Například pokud budu hledat dvojbarevné věci dotazem červena, modrá, žlutá, uživatel by měl dostat výsledky červenomodré věci, červenožluté věci, modrožluté věci.
bredy 12.2.2012 00:21  1408
Kingad 1406 tenhleten zápis mě nenapadl to je bez unionu, vyzkouším, díky. (vím určitě, že vždycky o stejné N-tice ANDů, protože ten generátor dotazu má někde zadáno, že některé tágy jsou disjunktní, třeba například, pokud si uživatel přeje hledat X,Y a já vím, že X vylučuje Y, nemůžu to hledat ANDem ale ORem... proto to budou stejný Ntice)
king King Born to be king - ... 11.2.2012 05:11  1407
Jinak ja bych na tohle SQL rozhodne nepouzil a sel po necem co se s tim poradi lepe, v tomhle pripade asi redis, i kdyby to melo byt treba jen jako dodatecny "index" k SQL databazi kterou bych stale bral jako kanonicky zdroj.

Pripadne si vybral alespon SQL db ktera ma typ pole a do ni ukladal ty tagy (opet treba jen jako denormalizaci dat ktere "ziji" jinde) a pak je to opet jeden trivialni SQL bez joinu).

Normalizace dat za kazdou cenu skodi vykonu i citelnosti imho. A i kdyz je to praktice na to si udrzet poradek (referencni integrita a spol) tak je casto mnohem uzitecnejsi mit data (i) denormalizovana prave na takoveto dotazy.
king King Born to be king - ... 11.2.2012 05:05  1406
Nejlepsi bys to mel to pomoci triggeru denormalizovat treba do bitoveho pole a pak je kazdy takovyhle dotaz pomerne jednoduchy a hlavne velmi efektivni.

dalsi moznost mi prijte (pokud vis kolik tagu budes chtit mit v jednom dotazu) tu data tabulku najoinovat dvakrat samu na sebe cimz dostanes trojice a ty pak jednodusse vyfiltrujes: 

SELECT

  data_id

FROM 

  data_and_tags as a

    INNER JOIN data_and_tags AS b ON (a.data_id = b.data_id)

    INNER JOIN data_and_tags AS c ON (a.data_id = c.data_id)

WHERE

  (a.name = 'A' and b.name = 'B' and c.name = 'X')

    OR

  (a.name = 'A' and b.name = 'B' and c.name = 'Y')

    OR

  ...

bredy 11.2.2012 01:11  1405
Hledání pomocí tagůZdravím, hledám nejoptimálnější variantu, jak hledat podle tagů a to následujícím způsobem

Mám 3 tabulky: 
Data, Tags, DataAndTags.


Organizace je zřejmá, v tabulce Data mám nějaké řádky, v tabulce Tags mám nějaké tágy a v tabulce DataAndTags mám ve dvou sloupcích provedeno propojení mezi daty a tágy. Je to prostě vztah N:M

Dejme tomu, že spojení označím 
Data.Id -> DataAndTags.Data_Id
Tags.Id -> DataAndTags.Tag_Id


A teď dotaz. Mám v tabulce Tags tyto tágy: A,B,C,D,E,F,G,....,Z a v tabulce Data je hromada dat, kde každý řádek má prakticky libovolnou kombinaci tágů.

Od uživatele mi přileze takovýto dotaz:
Najdi mi všechny záznamy, kde jsou vysačky 

(A and B and X) or (A and B and Y) or (A and C and X) or (A and C and Y)


On to tedy ten uživatel zadává jinak, on zadá spíš to, že ho zajímají položky s tágama A,B,C,X,Y ale protože tágy mají ještě nějakou vnitřní strukturu, kterou nepovažuji za důležitou zde řešit, nějaký query parser z toho výrobí výše zmíněný dotaz.

A teď jak to přepsat do SQL dotazu?

Zatím mě nenapadlo nic lepšího, než to rozdělit do 4 dotazů sloučených přes UNION a každá ta disjunktní množina se vyhodnotí dotazem seskládaným pomocí JOIN sama se sebou. Vstupem je vždycky tento součinový tvar a nedá se zatím zadávat negace (například, že nějaký tág vyloučím... ale možná to tam časem přibude, uvidím co bude říkat zákazník). Na úrovni vstupu se to dá optimalizovat jestě Karnaughovou mapou :-) ale do toho jsem se ještě nepouštěl
knedle knedle online - Krabice živých 30.1.2012 15:24  1403
tak imho plan v mysql neni
i kdyz nemuzu rict ze je to tutovka - ten force index ve specifikaci selectu taky neni , jen v komentarich - a sql na tomto "neznamem" prikazu nepada
knedle knedle online - Krabice živých 30.1.2012 15:15  1402
pepak [1401]: zkusim najit

zatim jsem dohledal jen, ze muzu definovat pouzite indexy: ... FROM ccr_news FORCE INDEX (ccr_news_insert_date_i) ...
pepak pepak - Pepak.net 30.1.2012 15:07  1401
Knedle: Ve Firebirdu na to je klíčové slovo PLAN, které můžeš přidat do SELECTu a kterým si vynutíš nějaký konkrétní prováděcí plán. MySQL určitě také bude mít něco takového.
themajkl themajkl All those moments will be lost in time - like tears in rain. 30.1.2012 14:34  1400
Nevím jak v mysql, ale u informixu lze do selectu vnutit direktivou, které indexy se mají použít. Něco jako
select {+index(jmeno_tabulky jmeno_indexu)}
.. atd

Podle mne to vyjmenování sloupečku udělá ve výsledku totéž, jen nepřímo, protože si to tak jinak poskládá svým algoritmem db stroj kvůli řazení a podobně.
knedle knedle online - Krabice živých 30.1.2012 14:26  1399
nekde pomohlo (zbytecne) doplneni sloupcu, ale to prece neni cesta

je nejaky zpusob, jakym zpusobem poskladat SQL dotaz tak, abych mel pod kontrolou to poradi v EXPLAIN ?
knedle knedle online - Krabice živých 30.1.2012 11:00  1398
asi chápu, ale moc do toho nevidím:

rozklíčoval jsem, že pokud z jedné (hlavní) tabulky přidám do selectu 2 sloupce (varchary)
což má za následek, že se přeskládají tabulky, ze kterých se to tahá (celkem 6) - což vidím v EXPLAIN

he?
pepak pepak - Pepak.net 30.1.2012 10:52  1397
Execution plan.
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt