abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    včera 22:33 | Nová verze

    Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.

    Ladislav Hagara | Komentářů: 0
    včera 17:44 | Zajímavý článek

    Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.

    karkar | Komentářů: 0
    včera 12:11 | Humor

    Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).

    Ladislav Hagara | Komentářů: 2
    včera 10:44 | IT novinky

    Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.

    Ladislav Hagara | Komentářů: 24
    včera 09:55 | IT novinky

    Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.

    Ladislav Hagara | Komentářů: 2
    včera 09:33 | IT novinky

    Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.

    Ladislav Hagara | Komentářů: 0
    včera 08:11 | Nová verze

    Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.

    Ladislav Hagara | Komentářů: 0
    29.4. 20:55 | Nová verze

    Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.

    Ladislav Hagara | Komentářů: 0
    29.4. 16:22 | Nová verze

    Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.

    Ladislav Hagara | Komentářů: 0
    29.4. 15:55 | Pozvánky

    Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových

    … více »
    Zdenek H. | Komentářů: 2
    Jaký filesystém primárně používáte?
     (58%)
     (1%)
     (9%)
     (21%)
     (4%)
     (1%)
     (2%)
     (0%)
     (1%)
     (3%)
    Celkem 496 hlasů
     Komentářů: 19, poslední včera 11:32
    Rozcestník

    Vložit další komentář
    17.10.2005 22:36 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    No možná sis ujasnil myšlenky, ale já jsem se v tomhle zápise dokonale ztratil :-). Co třeba napsat ty dotazy co provádíš?
    17.10.2005 22:45 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    Nenapadlo mě podívat se do bugu a že tam bude ten log :-).
    17.10.2005 22:48 Leoš Literák | skóre: 74 | blog: LL | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    select * from relace where typ_predka='P' and predek=42802 
    select * from polozka where cislo in (42803,42831) order by cislo
    select * from zaznam where cislo in (57550) order by cislo
    select soucet from citac where typ like 'P' and cislo=42802
    

    Ctverice zminenych dotazu. Posledni tri by sly celkem snadno aplikovat hromadne na vsechny clanky. Proste by tam tech cisilek trosku pribudlo :-)

    Ale ten prvni je v obecnem pripade nejhorsi. Zde ale vim, ze se bude menit jen cislo predka. Jenze stejne radeji hledam obecne reseni. Takze kdyz mam treba dvojice (A,1), (A,2), (B,3), (C,1), IMHO by resenim bylo:

    select * from relace where typ_predka='A' and predek in (1,2)
    select * from relace where typ_predka='B' and predek in (3)
    select * from relace where typ_predka='C' and predek in (1)

    A pak rucne projit vracene radky a podle sloupecku predek rozhazet udaje ke spravnym objektum.

    Zakladatel tohoto portálu. Twitter, LinkedIn, blog, StackOverflow
    17.10.2005 22:54 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    A potřebuješ vůbec všechny ty data? Potomci jsou diskuze?
    18.10.2005 10:14 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    Tohle jde určitě zkrátit na
    select * from relace where
      (typ_predka='A' and predek in (1,2)) or
      (typ_predka='B' and predek in (3)) or
      (typ_predka='C' and predek in (1))
    
    Ale jinak se v tom zatím moc nevyznám :-) Je to tak, že v tabulce polozka je honorář a hlavička diskuze a v zaznam je obsah článku? Šlo by sem ještě dát create table pro polozka a zaznam?

    Předpokládám, že ta čísla (42803,42831) a (57550) jsou z relace, a které je nebo je polozka a zaznam se pozna podle typ_potomka?
    18.10.2005 12:03 Leoš Literák | skóre: 74 | blog: LL | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    Aha, no jasne :-) Easy.

    Ta cisla jsou potomci v tabulce relace, tabulku urcuje sloupecek typ_potomka. Napriklad pro polozku je to 'P.

    Deleni obsahu clanku (zaznam) od hlavicky (polozka) je umyslne, mela to byt optimalizace, aby se dlouhy obsah nenacital pri listovani rubrik. Jak jsem vcera zjistil, tak se to nepovedlo ;-) Ale pujde to zoptimalizovat, kdyz uz o tom vim.

    Ted frcim na obed ..
    Zakladatel tohoto portálu. Twitter, LinkedIn, blog, StackOverflow
    18.10.2005 12:24 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    Deleni obsahu clanku (zaznam) od hlavicky (polozka) je umyslne, mela to byt optimalizace, aby se dlouhy obsah nenacital pri listovani rubrik.

    Nestačilo by nepoužívat 'select *'? Navíc u databází bývá zvykem, že v záznamu nejsou celé BLOBy, ale jen jakési handly na ně, ale nevím, jestli to tak dělá i MySQL.

    18.10.2005 13:43 Leoš Literák | skóre: 74 | blog: LL | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    Jenze ja si ihned nafetchuji cely obsah vcetne blobu a ulozim do cache.
    Zakladatel tohoto portálu. Twitter, LinkedIn, blog, StackOverflow
    18.10.2005 12:39 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    Otázka je, jak moc to optimalizovat na počet dotazů – ono by to samozřejmě šlo napsat jako jeden dotaz (OUTER JOIN), který bude v každém řádku ve spoustě sloupečků mít NULL, a pak si to v Javě rozebrat - jenže tím se IMHO moc neušetří. Předpokládám, že všechny dotazy běží nad jedním Connection – navázání spojení je pomalé, ale režie na dotaz/odpověď podle mne nebude tak velká, aby se vyplatilo vše uměle cpát do jednoho dotazu.

    No ale jak teď na to koukám, na vypsání seznamu článků v rubrice by měl stačit 1 SQL dotaz :-) Bez zdrojáků a struktury DB se to těžko odhaduje, ale zkusím to popsat abstraktně :-) Tož:
    SELECT *
    FROM relace AS Rserial, relace AS Rclanky
    WHERE Rserial.url = ? AND
      Rserial.cislo = Rclanky.cislo AND Rclanky.typ = 'P'
    ORDER BY Rclanky.cislo
    
    Tím bych měl získat čísla všech článků v seriálu. K nim potřebuji přidat obsah (zaznam) a třeba dvě položky z polozka – dejme tomu autor a honorar. Upravím tedy SELECT:
    SELECT *
    FROM relace AS Rserial, relace AS Rclanky, zaznam, polozka AS Pautor, polozka AS Phonorar
    WHERE Rserial.url = ? AND
      Rserial.cislo = Rclanky.cislo AND Rclanky.typ = 'P' AND
      zaznam.cislo = Rclanky.cislo AND
      Pautor.cislo = Rclanky.cislo AND
      Phonorar.cislo = Rclanky.cislo
    ORDER BY Rclanky.cislo
    
    Stejně by se do SELECTu přidal i počet položek. Na spojování tabulek jsou databáze optimalizované, pokud jsou na příslušných sloupečcích indexy, mělo by to být OK.

    Výsledkem SELECTu by měl být 1 řádek = 1 článek. Místo SELECT * si samozřejmě vyberu jen ty sloupečky, které potřebuji.

    Doufám, že tu nepíšu úplné nesmysly a půjde to na strukturu databáze napasovat :-)
    18.10.2005 12:46 Filip Jirsák | skóre: 68 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    Jak tak koukám do toho logu, asi nejde pospojovat položku s článkem přímo, ale zase pře relaci. Tedy:
    SELECT *
    FROM
      relace AS Rserial,
      relace AS Rclanky,
      zaznam,
      polozka AS Pautor,
      polozka AS Phonorar,
      relace AS Rautor,
      relace AS Rhonorar
    WHERE Rserial.url = ? AND
      Rserial.cislo = Rclanky.cislo AND Rclanky.typ = 'P' AND
      zaznam.cislo = Rclanky.cislo AND
      Pautor.cislo = Rautor.cislo AND
      Rautor.predek = Rclanky.cislo AND
      Rautor.typ_predka = 'P' AND
      Phonorar.cislo = Rhonorar.cislo AND
      Rhonorar.predek = Rclanky.cislo AND
      Rhonorar.typ_predka = 'P'
    ORDER BY Rclanky.cislo
    
    18.10.2005 13:42 Leoš Literák | skóre: 74 | blog: LL | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    Ono ani neni cilem mit vsechno v jedinem SQL dotazu. Pak by byl docela problem, jak cachovat vysledky a vubec, jak tvorit SQL dotazy a parsovat jejich vysledek. Preci jen univerzalni rozhrani ma vyhodu, ze jak se jednou napise, nemusi se o ne jiz starat, proste funguje. Takze ted tam vzdy je zaznam, ktery ale nepotrebuji a nekdy tam byvaji diskuse a honorare. V budoucnu muze pribyt janevimco a rozhodne nechci kvuli tomu studovat, co vsechno prestane fungovat.

    Takze spise mi jde o zefektivneni vrstvy persistence, aby zvladala hromadne nacitani dat nad skupinou vysledku. A to si myslim, ze zapis + diskuse uz resi.
    CREATE TABLE polozka (
     cislo INT AUTO_INCREMENT PRIMARY KEY,  -- jednoznacny identifikator
     typ SMALLINT,                          -- typ polozky (diskuse, faq, ..)
     podtyp VARCHAR(30) NULL,               -- podtyp
     data TEXT NOT NULL,                    -- XML 
     pridal INT(6) NOT NULL,                -- odkaz na uzivatele
     vytvoreno DATETIME,                    -- cas vytvoreni
     zmeneno TIMESTAMP NOT NULL             -- cas posledni zmeny
    );
    
    CREATE TABLE zaznam (
     cislo INT AUTO_INCREMENT PRIMARY KEY,  -- jednoznacny identifikator
     typ SMALLINT,                          -- typ zaznamu (HW, SW, clanek ..)
     podtyp VARCHAR(30) NULL,               -- podtyp
     data LONGTEXT NOT NULL,                -- XML 
     pridal INT(6) NOT NULL,                -- odkaz na uzivatele
     vytvoreno DATETIME,                    -- cas vytvoreni
     zmeneno TIMESTAMP NOT NULL             -- cas posledni zmeny
    );
    Zakladatel tohoto portálu. Twitter, LinkedIn, blog, StackOverflow
    22.10.2005 14:05 Leoš Literák | skóre: 74 | blog: LL | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    Ted se nestahuji zaznamy. Celkove nacteni rubriky jadernych novin kleslo z 2403 ms na 1466 ms. 39% je slusny vysledek, ale mi nestaci, tudiz delam ted na hromadnem nacitani potomku. Pak budu moci hromadne nacist i diskuse a verim, ze se dostanu nekde k 750 milisekundam. A az nejak rozumne vyresim nacitani ctennosti clanku, mohlo by to klesnout na ctvrtinu skundy. Uvidime. Sledujte bug pro aktuality :-)
    Zakladatel tohoto portálu. Twitter, LinkedIn, blog, StackOverflow
    17.10.2005 22:48 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    • Proč text porovnáváš pomocí LIKE když ho nepotřebuješ?
    • Jaké tam jsou indexy? Některé dotazy mi připadají dost pomalé.
    • Zkoušel ses podívat na EXPLAIN u složitějších dotazů?
    17.10.2005 22:51 Leoš Literák | skóre: 74 | blog: LL | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    ALTER TABLE relace ADD INDEX in_potomek (typ_potomka,potomek);
    ALTER TABLE relace ADD INDEX in_predek (typ_predka,predek);
    ALTER TABLE relace ADD INDEX in_predchozi (predchozi);
    ALTER TABLE relace ADD INDEX in_url (url);

    Indexy jsem delal podle EXPLAIN, ale spise jen amatersky.

    Pokud jde o prvni dotaz, mas pravdu, take jsem si ted vsimnul, ze ten LIKE je zbytecny, kdyz znam presnou hdonotu. Ale bude to poznat na vykonnosti, kdyz ma sloupecek vzdy jediny znak a ten strcim do vyrazu? Pak snad nebude rozdil mezi porovnanim a LIKE, ne?

    Zakladatel tohoto portálu. Twitter, LinkedIn, blog, StackOverflow
    17.10.2005 23:05 Michal Čihař | skóre: 61 | blog: Bláboly | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    Nevím nakolik je optimalizátor chytrý, jestli zkoumá že LIKE je zbytečný a nechce se mi generovat dost dat, abych to vyzkoušel :-).

    A vůbec co vnořené dotazy? Připadá mi, že by se tam daly použít a pak ti dotazů pár ubyde :-).
    18.10.2005 00:14 Martin Tůma | skóre: 39 | blog: RTFM | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze

    Chápu to dobře, že každej jednotlivej příspěvek v diskusi získáváš jedním SQL dotazem? V případě, že ano, nebylo by mnohem efektivnější získat všechny příspěvky z jednoho vlákna pomocí 1 dotazu (například podle UID prvního-kořenového záznamu) a ty pak srávně "pospojovat" podle nějakého identifikátoru udávající pozici ve stromu příspěvků u jednotlivých příspěvků až v aplikaci?

    Každý má právo na můj názor!
    18.10.2005 08:33 Zdeněk Štěpánek | skóre: 57 | blog: uz_mam_taky_blog | varnsdorf
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    Zdravim

    Nejsem zadny DB expert, ale jen premyslim nahlas. Ty tema dotazama nactes data a pak z nekolika nactenych tabulek vybiras data a spojujes je dohromady. Otazka je, zda je to zpomaleni v databazi nebo v jave (kde se ty data spojujou a vybiraj z nactenych tabulek).

    Osobne si myslim, ze nejdyl trva java, protoze ty dotazy opravdu nejsou zadny slozity veci. A jelikoz si myslim, ze prace s daty by mela byt v databazi rychlejsi nez to rucne kodovat v jave, nechal bych co nejvice hruby prace na databazi. Takze bych vyuzil spojovani tabulek a/nebo vnorene dotazy.

    Nevim ted co je to za databazi (nebudu to lovit, tipuju Postgres), neslo by si tam nadefinovat vlastni procedury, mohly by byt vykonnejsi nez java.

    Priklad na spojovani tabulek z praxe, prijde mi to skoro to samy. I kdyz nevim, jestli to zrovna tobe ma smysl vykladat.

    V jedny tabulce mam hash ID klienta a jeho IP adresu (id, ip). V druhe tabulce mam opet hash ID klienta a jeho cele jmeno (id, name). Ve vysledku potrebuju dvojice cele jmeno a ip adresa (name, ip). Klasicke reseni by bylo nacist tabulku s ip adresama, cyklicky parsovat radky a ziskane hash ID davat do dotazu do druhe tabulky (selectname from druha_tabulka where id=$id). Tohle funguje a na kazdy radek to sezere dva dotazy. Lze ale pouzit spojeni tabulek, sql dotaz vypadfa takhkle:

    select name,ip from prvni_tabulka, druha_tabulka where prvni_tabulka.id = druha_tabulka.id

    Co to vraci je snad videt jasne.

    Zdenek
    www.pirati.cz - s piráty do parlamentu i jinam www.gavanet.org - czfree varnsdorf
    22.10.2005 15:52 Honza Král | skóre: 3 | Praha
    Rozbalit Rozbalit vše Re: Prosba o pomoc s optimalizací databáze
    myslim, ze se jedna o MySQL, taky jak na to koukam, tak si rikam, ze by dost slo resit/zjednodusit pomoci ulozenych procedur a hlavne vhodne nadefinovane view...

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.