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

Já Vánoce juchuchu
oslavím na Lopuchu!

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Archiv klubu Database (mysql,...) [ŽP: neomezená] (kategorie Programování) moderuje melkor_unlimited.
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
   
[ 414 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
al3x 24.11.2005 15:45  243
Ach jo. Vubec si me tu nevsimejte. Zkusim se nejdriv naucit cist nez budu neco takovyho plkat. Mel jsem celou dobu pocit, ze prosazujes uplne jiny reseni (ktery jsem cetl nekde na webu a - nevim proc - nejak jsem si ho spojil s tebou).
Mno nic, tak sry.
bredy 24.11.2005 14:47  242
Al3XTo co píšeš jsem nepochopil. Zadání bylo nalézt náhodný záznam. Pokud záznamy v tabulce mažeš pomocí DELETE, tak bys neměl narážet na nesmazané záznamy, protože jejich počet je za každých okolností 0. Pokud mažeš záznamy tak, že si je označíš, tak by se samozřejmě oba selekty musely opravit, aby pracovali pouze se záznamy, které nejsou označené jako smazané. V tom případě by COUNT(*) už neměl složitost 1, ale složitost v nejhorším případě N (pokud je v indexu, tak je to lepší, například jedna má implementace BTree umí zjistit počet záznamu v zadaném indexu taky v jednotkovém čase - takže předpokládám, že u MYSQL je to ještě lépe optimalizované).

Problém, který toto řešení má, je to, že když mezi SELECT COUNT(*) a SELECT LIMIT vymaže záznam a náhodou ti padne náhodné číslo vyšší, než současný počet záznamů v tabulce, který se změnil po tom, co jsi udělal dotaz na počet. To že se mažou záznamy mimo tuto část nevadí.
al3x 24.11.2005 13:45  241
Bredy [240]: To ano, ale ne vsechny databaze jsou pouzivany jen jako staticke archivy. Operace mazani neni nic zas tak neobvykleho. I pokud si predstavim hloupej priklad tabulky, ktera si pamatuje vypujceny knihy v knihovne, tak hned narazim. Ta tabulka sice bude mit radove stale stejnej pocet radek (vypujcenych knih), ale protoze se bezne vrati stejne knih (delete) jako se jich pujci (insert), predpokladame-li, ze prumerna vypujcni doba je jeden mesic, tak kazdym mesicem klesa pravdepodobnost, ze se tim svym algoritmem nekam trefis na 1/n, kde n je pocet mesicu, kdy je ta db v provozu.
Za rok provozu budes muset udelat pres deset selectu, aby jsi nasel zatim nesmazanej radek.

Ale je to elegantni reseni, kdyz to budes odevzdavat, tak na pokusnych datech pujde vse v pohode. Jen casem se jim to bude zadrhavat vic a vic, ale to uz te nezajima, protoze jsi svuj produkt uz davno prodal..
bredy 24.11.2005 13:29  240
AL3XProblém nastává jen v okamžiku, kdy někdo z tabulky záznam smazal a zrovna náhodné číslo vrátilo hodnotu mimo rozsah počtu záznamů. I kdyby tam byl velký provoz, pravdepodobnost je malá.

Mimochodem, technika opakování výpočtu v konkurenčním prostředí se používá dost často i v jiných oblastech. Často také proto, že je mnohdy rychlejší, než vytvářet zámky a transakce. Není na tom nic špatného. Předpokládá se přitom, že ke kolizi nedochází až tak často. V níže uvedením případě je kolize pouze ve vyjmenovaných situacích a tedy tvrdím, že tuto podmínku to splňuje.
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 23.11.2005 08:59  239
huhdiky, o diky, replace mezeru za nic me nejak nenapadlo...
al3x 23.11.2005 01:01  238
huh [237]: To je fakt. Ale stejne mi to reseni moc nesedi. Hlavne proto, ze neni univerzalni, jakmile to budu delat nad tabulkou, ktera se casto meni, tak to muze delat dost osklivy veci. Navic na to prijdes az po roce pouzivani systemu a ne hned, protoze ze zacatku se budes trefovat dobre. Proste hnus.
huh huh 23.11.2005 00:31  237
AL3X [235]: to poznas, protoze tu nulu vrati uz COUNT
huh huh 23.11.2005 00:26  236
tvx [233]: odstranit mezery lze treba pomoci fce REPLACE(); vyhledat podretezec umi treba funkce INSTR() nebo LOCATE(); nepises co za db, tak predpokladam mysql
al3x 22.11.2005 19:14  235
Bredy [234]: To klidne nakonec muzes opakovat 10x, pokud je to pouzivana tabulka na (insert/delete), pokud bude prazdna a zase to zvlast neosetris, tak se zacyklis. Proste dost osklivy reseni.
bredy 22.11.2005 17:43  234
huhTo není problém. V nejhorším ten select vrátí 0 záznamů, což znamená, že musím posloupnost dotazů opakovat.
tvx tvx Myslet si, že svět je JEN takový, jak - ho v daný čas můžeme pochopit je hloupé. 22.11.2005 16:36  233
1. kterak nějak ideálně selektovat na jednocharovej substring? nic jinýho než like asi neni, co?

2. kterak ze stringovýho pole kde je nějaký finanční numero s mezerama mezi tisíci a miliony, numero udělat? neni třeba nějaká vestavěná funkce na vyházení mezer z řetězce?
kdokoliv Kdokoliv Nevidím důvod dělat cokoliv bezdůvodně. - http://kkl2401.wz.cz 20.11.2005 11:24  232
Nevim, jak v mysql, ale aspon v Oraclu je rozhodne lepsi select count(sloupecek), kde sloupecek je takovej, pres kterej ma ta tabulka index. Bezi to rychlejc nez select count(*). Tezko rict proc a jestli to treba novejsi verze Oraclu uz neopravily, ale pred nejakejma dvema rokama jsme na to v jedny nemaly aplikaci narazili.
huh huh 20.11.2005 10:16  231
akorat, pokud se z ty tabulky i maze, tak to bud musi bejt v transakci nebo jinak rucne osetreny
bredy 20.11.2005 09:33  230
NiximorTohle používám já a nevídím v tom problém. Počet záznamů lze zjistit pomocí SELECT COUNT(*) FROM table který je prý hodně optimalizovaný (prostě vrátí počet záznamů v tabulce a nic nepočítá)
al3x 17.11.2005 01:48  229
Tak jsem se v tom mysql hodne spletl.

when selecting a single random row you have to use a query like this: SELECT ... FROM my_table ORDER BY RAND() LIMIT 1.
as explain shows, mysql optimizes this VERY badly (or may be better said, doens't optimize it at all): it uses an temporary table and an extra filesort.

Hloupy je, ze moc lepsich metod jsem nenasel. :(

[ 414 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt