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: xqhglhb
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
knedle knedle online - Krabice živých 20.8.2013 15:28  1466
docela by me taky zajimalo

- jak si to vubec predstavujes?
huh huh 20.8.2013 12:49  1465
Analýza SQL dumpůExistuje nějaký nástroj, ideálně interaktivní pro prohlížení, případně porovnání SQL (MySQL) dumpů?
bredy 5.8.2013 11:50  1464
Tak si zatím odpovím sám. Nic jsem nenašel, tak jsem si spíchnul následující funkci:


DELIMITER ;;
CREATE FUNCTION `WaitForMsg` (`revision` int) RETURNS int(11)
READS SQL DATA
BEGIN
DECLARE currev INT;
DECLARE sleepres INT;
SELECT `AUTO_INCREMENT` INTO `currev` FROM information_schema.tables WHERE table_name='messages' AND table_schema = DATABASE();
SET sleepres = 0;
WHILE (currev = revision AND sleepres = 0) DO
SELECT SLEEP(0.5) INTO sleepres;
SELECT `AUTO_INCREMENT` INTO `currev` FROM information_schema.tables WHERE table_name='messages' AND table_schema = DATABASE();
END WHILE;
RETURN currev;
END;;
DELIMITER ;


Předpokladá, že tabulka 'messages' má auto_increment

Použití:

SELECT WaitForMsg(0) -- pri prvnim zavolani vraci AUTO_INCREMENT
SELECT WaitForMsg(10) -- pokud je AUTO_INCREMENT = 10, zustane viset dokud se to nezvedne na 11 a to pak vrátí

bredy 5.8.2013 10:32  1463
Čus zdravím.

Napadá někoho, jak v mysql udělat něco jako zpětnou notifikaci o změně nějaké tabulky? Myslím na klienta. Něco jako. že bych v rámci jednoho spojení čekal až nastane událost a až by ta událost nastala, tak by se mi ten příkaz vrátil splněny.

Napadlo me treba triggerem odemykat a zamykat tabulky. Nenasel jsem tam nic jako event objekt a jestli jo, tak jsem slepej a diky za radu.
bredy 18.4.2013 17:59  1462
Zdá se, že mu opravdu vadi `partnerId`=12902 vzhledem k tomu, že to je součástí primárního klíče. Byť je vlastně irelevantní, dostane stejnou hodnotu, jakou by měl mít, ale přesto to vadí.
huh huh 22.3.2013 23:15  1461
Bredy [1460]: Zní to jako nějaká variace na tohle. Bez definice klíčů těžko soudit. Jediný, co moc nechápu, kde se vzalo to F91A71406E382E2AC41B7AD05CB01FF0.
bredy 22.3.2013 16:14  1460
Rozumíte někdo téhle chybě?


Duplicate entry 'F91A71406E382E2AC41B7AD05CB01FF0-12902' for key 2' on query. Default database: 'register'. Query: 'INSERT `computer_reg` (`computerHash`,`ip`,`firstReg`,`lastReg`,`partnerId`,`count`) VALUES ('9D6AE2DA9311E532A4EB37A96078E390','89.24.9.224',NOW(),NOW(),12902,1) ON DUPLICATE KEY UPDATE `ip`='89.24.9.224',`lastReg`=NOW(),`partnerId`=12902, count = count + 1'

Doporučuji si všimnou ON DUPLICATE KEY UPDATE
themajkl themajkl All those moments will be lost in time - like tears in rain. 18.10.2012 06:08  1458
knedle [1457]: Ne, to je poslední řádek té zálohy. Začal jsem ji rozdělovat a zjistil tohle....
knedle knedle online - Krabice živých 17.10.2012 22:47  1457
to je jen omezeni (nastaveni) na strane hostingu

rozdel to na několik souboru a ty importuj samostatně
themajkl themajkl All those moments will be lost in time - like tears in rain. 17.10.2012 21:14  1456
Samozřejmě při vytváření zálohy všecko tvrdilo, že OK.
themajkl themajkl All those moments will be lost in time - like tears in rain. 17.10.2012 21:13  1455
ChaUdělal jsem zálohu DB phpBB.. starý hosting šel do kopru. Obnovuju na novém hostingu, je to velký soubor, musel jsem ho pri import rozdělovat. Abych nenapínal, poslední řádek je:
Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 64225281 bytes) .. atd
Cili je to celé v prdeli :-)))
pepak pepak - Pepak.net 7.9.2012 05:09  1454
EtDirloth: IMHO to nemá cenu, pokud bude chtít oba údaje (počet kladných, počet záporných), tak bude stejně muset projít celou tabulku. Něco by se dalo ušetřit, kdyby zjišťoval třeba jen počet záporných a záporných bylo výrazně méně než kladných, ale pro požadované výstupy jsou indexy k ničemu.
themajkl themajkl All those moments will be lost in time - like tears in rain. 6.9.2012 22:01  1453
EtDirloth [1452]: Indexy - jasně. Ale já jsem tím vždycky řešil zadání typu "potřebuju vedle sebo počty/sumy v pondělí, v úterý..." a tam nemá smysl o nějakých indexech uvažovat.
etdirloth EtDirloth 6.9.2012 21:31  1452
knedle: presne to som ti chcel napisat, ze ti stacia dva agregaty (suma alebo pocet)
themajkl: to sa nemusi vyplatit pri velkych poctoch, pretoze tam nevies pouzit index; osobne by som si tam dal druhy stlpec -> "like_positive" (dislike indikuje nulou) a skusil kludne: 
select count(*), sum(like_positive) ... group by interpret_id, song_id
a potom porovnal query plan oproti dvom samostatnym dotazom s where [like|dislike]
knedle knedle online - Krabice živých 6.9.2012 21:01  1451
themajkl [1449]: díky, funguje 

SELECT `interpret_id`, `song_id`, SUM(`like`) as likeRating,
SUM(case when `like` > 0 then 1 else 0 end) as plusLike,
SUM(case when `like` < 0 then 1 else 0 end) as minusLike
FROM `rating`
group by `interpret_id`, `song_id`
order by likeRating ASC
[ 1008 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt