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

Tolik rozruchu
jen v Lopuchu

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: rccylsv
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
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.
knedle knedle online - Krabice živých 30.1.2012 10:37  1396
dotazmám 2 selecty - shodné části FROM WHERE ORDER LIMIT
rozdíl jen u SELECT, kde

ten sql, který tahá více sloupců - z více tabulek
je rychlejší než ten, který jich tahá méně

WTF? jakej je důvod?
knedle knedle online - Krabice živých 10.1.2012 09:49  1395
yop dik max_allowed_packet...
themajkl themajkl All those moments will be lost in time - like tears in rain. 10.1.2012 09:46  1394
http://en.wikipedia.org/wiki/Wikipedia:Database_dump_import_problems ?
themajkl themajkl All those moments will be lost in time - like tears in rain. 10.1.2012 09:44  1393
Teda mě to přijde (při zkušenosech s jinou db), že přeteče nějaké místo, co má vyhrazené na jednu transakci nebo podobně, ale pak bych čekal, že se s tím musí počítat a ohlásti to nějak lidsky, ne nemožností připojení...
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt