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 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
včera 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 1
včera 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
včera 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 2
včera 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 4
včera 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 3
včera 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 2
17.10. 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 10
17.10. 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
17.10. 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (13%)
 (2%)
 (0%)
 (2%)
 (73%)
 (11%)
Celkem 63 hlasů
 Komentářů: 4, poslední včera 21:50
    Rozcestník

    Dotaz: Náročnost inner joinu s a bez limitu řádků

    23.4.2011 18:36 vasek
    Náročnost inner joinu s a bez limitu řádků
    Přečteno: 323×
    Ahoj. Provádím docela náročné dotazy (select na spojení několika statisíceřádkových tabulek) v databázi mysql. Potřebuji vypsat 30 řádků. Je nějaký rozdíl co se týče složitosti spojení v mysql jestli provedu už dotaz s parametrem LIMIT nebo jestli až v aplikaci (php) vypíšu prvních 30 řádků? Jde o to, že LIMITem v mysql nepostihnu všechno (aplikace má ještě nějaké vnitřní kontroly).

    Odpovědi

    poky74 avatar 23.4.2011 19:16 poky74 | skóre: 36 | blog: Zápisník | Vrchlabí
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků

    Jestli jsem to správně pochopil , tak jste strašné prase =-o.

    Takže vy selectujete několik 100 tisícovích tabulek a použijete jenom 30 řádků? Už jak to slyšim tak se mi ježí chlupy na zádech...

    PS. Jaké vnitřní kontroly?

    Chcete Linuxové samolepky nebo Tuxe na klíče? ->
    23.4.2011 20:04 vasek
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    A to mám selectovat 100 000 řádků jenom proto, že je ta tabulka má? To by bylo trochu stupidní vykreslovat potom webovou stránku která má pár gigabajtů. Jednou z těch vnitřních kontrol je např. poměrně složitý mechanismus detailního oprávnění, který se nedá "vimplementovat" do databáze.
    23.4.2011 20:11 ghost
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    dejte konkretni priklad, urcite to nepujde rozlozit alespon do vice kroku? Pouzit sice vice, ale levnych dotazu a pak az ten samotny pro vyber? patricne upraveny aby vyzvedl jen mnozinu ziskanou z predchoziho kroku?
    poky74 avatar 23.4.2011 20:14 poky74 | skóre: 36 | blog: Zápisník | Vrchlabí
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků

    Ptáte se jestli je rozdíl v tom, jestli používat "limit" na vrstvě databáze nebo aplikace, z toho plyne že bez limitu se sellectuje vše, proto se na to ptám...

    Ale k věci, tohle nasvědčuje o špatném návrhu aplikace/databáze

    Chcete Linuxové samolepky nebo Tuxe na klíče? ->
    23.4.2011 20:08 ghost
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Principialne ano a velky. Ty vyselectovane radky jsou v db ulozeny v nejake temporary table. A co zjistit ta omezeni predtim nez spustite samotny select? Jak ta kontrola vypada? Jsou to dalsi nejake dotazy do db?
    23.4.2011 20:26 vasek
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Ta kontrola vypadá tak, že načtu řádek z databáze a na základě dat z těch selectovaných sloupců (někdy i na základě předchozího řádku) rozhoduji o tom, které údaje zobrazit a které ne, případně které pozměnit. Aby se ta kontrola dala provádět, musím to z té databáze mít už načtené. Dříve jsem to řešil tak, že jsem při selectu za where dával ta omezení (oprávnění), jenže teď se mechanismus oprávnění dost rozšířil a taková podmínka where by byla hodně moc dlouhá a pro databázi dost neefektivní (dost často jsou používány i regulární výrazy).
    23.4.2011 20:38 ghost
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Hm, tak na prvni pohled to vypada na hodne spatne navrzenou databazi - zejmena nedodrzeni normalnich forem. V takovemto pripade si bez podrobnejsiho seznameni netroufam navrhnout lepsi reseni. Mimochodem, Vasek M. ?
    23.4.2011 20:59 vasek
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Celá databáze je ve 3NF, indexy jsou tam kde mají být a obecně je to řekl bych na možnosti udělané dobře. Ty oprávnění jsou tam dodělávané později. Hoodně dlouho jsem řešil jak to co nejlépe navrhnout aby to vyhovovalo požadavkům. Neříkám, že by se to nedalo rozložit do selectu jako součást dotazu, ale když má uživatel desítky různých oprávnění typu může číst/zapisovat ... sloupec ten a ten pouze pokud je ve zbývajících to a to tak taková podmínka už by byla minimálně pár tisíc znaková. Hlavně si myslím že mysql si dobře neporadí z těmi regexpy (i když by to umět mělo).
    23.4.2011 20:59 vasek
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Mimochodem, Vasek M. ?
    ne
    23.4.2011 21:08 ghost
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    když má uživatel desítky různých oprávnění typu může číst/zapisovat ... sloupec ten a ten pouze pokud je ve zbývajících to
    O jakou aplikaci se jedna (aspon obor)? Zkus to rozepsat trosku podrobneji - desitky ruznych opravneni. Z popisu predpokladam spravne, ze opravneni jsou definovana az na uroven sloupcu? Co v tech sloupcich treba je?

    23.4.2011 21:41 vasek
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Je to takový centrální dohled nad jednočipovými externími jednotkami a zároveň synchronizace uživatelských účtů z různými webovými aplikacemi. Těžko se to dá popsat, je to dost specifická věc.
    selectnuté sloupce tabulek vypadají nějak takto:
    
    zamestnanec_id | jmeno | email | skupina | ... | zar1_hodnota_typ | zar2_hodnota_val | ... | zar3_....
    
    
    Sloupce jsou většinou varchar, občas nějaký int. A ano je to definováno až na úroveň sloupců. Oprávnění mi mohou říci třeba to, že uživatel se jmenem pepa a emailem pepa@mail.cz muze cist hodnotu zar2_hodnota_val, ktera je v rozsahu 50-80 a jejiz nazev je /c(.*)[ax]/ nebo jejiz hodnota je 60-90 a zároveň je uživatel ve skupině skupina.

    Mimochodem teď jsem zkusil vyselektovat ty hodnoty bez LIMITu a limitovat to až v aplikaci a žádné zpoždění se nekonalo, funguje to krásně rychle, řekl bych že malinko rychleji než s těmi původními právy které byly v podmínce where. Jak je to možné? Mimochodem používám v php PDO a prepared statements, 30x fetchnu řádek a pak prepared statement zahodím.
    23.4.2011 21:49 vasek
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Teda samozřejmě že to zpoždění by pak nastalo při aplikaci oprávnění (prošlo by se hodně řádků), ale tahle to funguje rychle.
    23.4.2011 22:09 ghost
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    selectnuté sloupce tabulek vypadají nějak takto:
    zamestnanec_id | jmeno | email | skupina | ... | zar1_hodnota_typ | zar2_hodnota_val | ... | zar3_....
    
    takze ve vysledku se objevuje zarX_hodnota_typ a zarX_hodnota_val, kde X muze byt 0 az X ? tzn. promenny pocet sloupcu ve vysledku?
    Sloupce jsou většinou varchar, občas nějaký int. A ano je to definováno až na úroveň sloupců. Oprávnění mi mohou říci třeba to, že uživatel se jmenem pepa a emailem pepa@mail.cz muze cist hodnotu zar2_hodnota_val, ktera je v rozsahu 50-80 a jejiz nazev je /c(.*)[ax]/ nebo jejiz hodnota je 60-90 a zároveň je uživatel ve skupině skupina.

    Toto opravdu silne zavani spatne navrzenou databazi! Predpokladam, ze neexistuje vazebni tabulka napr. uzivatel_smi_cist_zarizeni ? a dalsi vazebni tabulky realizujici takto prava? Opravdu bych na to sel nejakou rozumnou dekompozici - zkratka podobnou logikou jako se chovaji ruzne ORM. NApriklad v prvnim kroku vytahnout uzivatele, v druhem skupinu, ve tretim vsechny jednotky na ktera ma prava on, na ktere skupina, atd ... Minimalne z toho duvodu, aby ses alespon vyhnul zbytecnemu joinovani. Ve vysledku uz muzes vyselektovat jen ty jednotky na ktere ma pravo (jejich idecka mas z predchozich kroku) a aplikovat na ne pripadne dalsi slozitejsi selekt.
    Mimochodem teď jsem zkusil vyselektovat ty hodnoty bez LIMITu a limitovat to až v aplikaci a žádné zpoždění se nekonalo, funguje to krásně rychle, řekl bych že malinko rychleji než s těmi původními právy které byly v podmínce where. Jak je to možné? Mimochodem používám v php PDO a prepared statements, 30x fetchnu řádek a pak prepared statement zahodím.
    Neni to nacachovane? Kolik je ve vysledku radku? Zalezi co vsechno bylo v te podmince WHERE, od urcite slozitosti dotazu (alespon v MySQL) se vyplati rozdelit jeden slozity dotaza na vice malych.
    23.4.2011 22:25 vasek
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    X je nějakých 10 a mění se to velmi velmi zřídka (+-1). Ale to co jsem uvedl už je výsledek po inner joinu. Standardně se dívám jen do jedné z tabulek, ale občas to potřebuji zobrazit všechno. Vazební tabulky mám jen typu uživatel-skupina a skupina-práva. Ostatní oprávnění bohužel pomocí vazebních tabulek realizovat nejdou. Obešel bych se asi i bez regulárních výrazů, ale musel bych to nahradit LIKE znaky % a _ abych pomohl databázi a i tak by vazební tabulky nešlo použít.
    Neni to nacachovane? Kolik je ve vysledku radku? Zalezi co vsechno bylo v te podmince WHERE, od urcite slozitosti dotazu (alespon v MySQL) se vyplati rozdelit jeden slozity dotaza na vice malych.
    Nekešované to není, zkoušel jsem vybírat 300 řádku postupně s různými OFFSETy a LIMIT jsem nastavoval na 1000000 a zkoušel jsem to i bez LIMITu. V té době nebylo v podmínce where nic. Předtím když jsem zkoušel ten LIMIT 300 v sql, tak tam byly asi 4 podmínky LIKE.
    23.4.2011 22:41 ghost
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Proc musis pouzivat pro filtrovani regularni vyraz nebo like? Uzivatel to vyhledava podle jmena? To nejde pouzit primarni klic? Ci nazvy jednotek znaci i jejich pripadnou skupinu? Treba c01,c02,b01,d03 tak ty chces vybrat vsechny jednotky ze skupiny c?
    Kdyz uz to chces filtrovat na strane aplikace, nebo ti nic jineho nezbyva, tak se zkus zbavit alespon co nejvice joinu. Jeste bych mozna uvazoval, jestli to povaha aplikace vubec dovoli, o duplikaci te tabulky ze ktere filtrujes a udelal jeji kopii do tabulky, ktera ma jako storage engine Memory ... at to jede aspon rychle.
    Jeste by melo zajimal zpusob, jakym to v te aplikaci filtrujes. Ale to jen tak ze zvedavosti.
    23.4.2011 23:05 vasek
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Na memory storage nemám dost paměti (několik GB do budoucna). V té aplikaci filtruji (pokud potřebuji) všechny sloupce a porovnávám hodnoty příp. (NOT) LIKE hodnota. Nakonec to asi vyřeším kompromisem: v 1. kroku vyberu všechno aby to odpovídalo filtrování a zároveň aplikuji jednoduchá práva, potom pro jednotlivé tabulky budu aplikovat práva postupně při čtení.
    23.4.2011 23:10 ghost
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Vyzkousej, uvidis sam. Mne se porad nezda navrh db, ale tak nechme to konovi ... Jelikoz toho vic nevim, tak uz me zadny jiny zpusob nenapada. Chtelo by to dost detailnejsi popis ...
    GeoRW avatar 24.4.2011 07:47 GeoRW | skóre: 13 | blog: GeoRW | Bratislava
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    tiez si myslim, ze to mas zle navrhnute; urcite sa to da realizovat na urovni databazy priamo do datoveho modelu prip. si vytvorit par procedur, finkcii na databaze; davat tuto logiku do aplikacie v PHP je nezmysel
    "This is to be taken with a grain of salt." ACBF - Advanced Comic Book Format
    24.4.2011 14:08 vasek
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Pouze částečně by to šlo realizovat na úrovni databáze. Dejme tomu že chci změnit řádek v tabulce na něco. Nejprve si ale musím projít oprávnění, abych zjistil na co to mohu změnit.
    Např.
    
    tabulka:
    zamestnanec_id | jmeno | email | skupina
    
    původní řádek:
    1, josef, jose@mail.cz, externiste
    
    nový řádek:
    1, josef, josef@mail2.com, dohled
    
    Co když mi oprávnění závisí na sloupcích email a skupina, které jsou na sobě závislé. To bych pak musel aktualizovat po sloupcích a to by bylo dost zlé. Kdybych měnil 20 sloupců, musel bych pro každý z nich zavolat funkci do db JE_OPRAVNEN(...), přičemž při každém volání této funkce by se znovu musely projít oprávnění. Kdežto když to řeším na úrovni aplikace, tak mi stačí dočasně řádek upravit a jednou prohnat kontrolou oprávnění ještě před tím než to zapíšu do databáze. Pokud nepočítám nějaké "hloubkové" procházení dat, tak už tady je "rozdíl složitosti" n^2 : n, a to nepočítám čas potřebný pro komunikaci s db.
    24.4.2011 14:16 vasek
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Navíc pokud mám přístup k řádkům s hodnotami .. jose@mail.cz, externiste nebo ..josef@mail2.com, dohled tak ani nemohu měnit hodnoty postupně.
    24.4.2011 14:17 vasek
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Nicméně také sem mi nelíbí realizace na úrovni aplikace, takže jestli mátě nějaký kostruktivní návrh jak to provést na úrovni db, sem s ním (konstruktivním návrhem nepočítám dočasné transakce).
    25.4.2011 09:58 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Oprávnění mi mohou říci třeba to, že uživatel se jmenem pepa a emailem pepa@mail.cz muze cist hodnotu zar2_hodnota_val, ktera je v rozsahu 50-80 a jejiz nazev je /c(.*)[ax]/ nebo jejiz hodnota je 60-90 a zároveň je uživatel ve skupině skupina.
    Tady by pomohlo mít ta oprávnění předpočítaná v separátním sloupci abyste nemusel v každém dotazu vyjadřovat takhle složité podmínky. Předpočítání můžete dělat při insertu nebo třeba periodicky.
    In Ada the typical infinite loop would normally be terminated by detonation.
    25.4.2011 17:58 l0gik | skóre: 22
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Co se týče přístupu k zařízením s hodnotou 50-80, tak tato zařízení by měla tvořit nějakou "logickou" skupinu, ne? Tak zavést do databáze tu skupinu a oprávnění k nim. Celý se Ti to najednou smrksne na problém, že máš uživatele, ty jsou členuy různých skupin a ty skupiny maj práva k různým výrobkům.

    Uživatel - (je v) Skupině uživatelů - (má práva k) Skupině výrobků - (má práva k) výrobkům

    Vypsat všechny výrobky, ke kterejm mám práva, popř. vyselektit jeden výrobek, pokud k němu mám práva, je pak dosti efektnivní záležitost jednoho rekurzivního dotazu.

    Navíc Ti to bude automaticky podporovat vnořené uřživatelské skupiny, vnořené skupiny výrobků atd... A když si napíšeš vhodně modely, tak Ti bude skládat selekty pro zjišťování práv automaticky na jednom místě.

    25.4.2011 21:13 kuka
    Rozbalit Rozbalit vše Re: Náročnost inner joinu s a bez limitu řádků
    Obecne toto nelze rict. Za urcitych okolnosti muze klauzule limit ovlivnit plan provedeni dotazu ve smeru pouziti indexu a tim to radove zrychlit. Pro takto "vystizne popsanou" situace ale tezko rict.

    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.