Příspěvky

376

Server / Re:Porovnání SQLite vs. MySQL

« kdy: 18. 09. 2016, 20:09:54 »

Zápisy šly jeden po druhém

To je právě u engine, který nepodporuje transakce, dost ošemetné tvrzení. V případě transakcí je „jeden po druhém“ pro všechny možné případy jasně definováno. Ale když tam transakce nemáte, „jeden po druhém“ asi znamená, že to bylo v příslušném programu za sebou – z hlediska databáze to ale může znamenat cokoli. Ono kdyby šlo „jeden po druhém“ zařídit bez transakcí, tak se s transakcemi nikdo nebude obtěžovat…

Ano, "jeden o druhém" znamená, že to tak bylo napsané v programu. Teď zapsala program do databáze měření zařízení číslo jedna, za deset vteřin se zapsalo měření zařízení číslo dva a tak dál. Jestli to databáze zapisovala pozpátku nebo na přeskáčku, jestli si to napsala do keší, rovnou na disk nebo do svého notýsku, je myslím interní záležitostí té databáze a programu to může být naprosto ukradené. Považoval bych ale i u myisam za celkem samozřejmé, že jedna změna jednoho záznamu (update tabulka set něco where primarni_klic=1, kde klíč se vyskytuje v tabulce pouze jednou) bude atomární (tj. bude fungovat jako by byl zapnutý autocommit) a po návratu z "úspěšně" provedené operace update budu schopný přečíst naposledy zapsanou hodnotu. Při absenci transakcí nebo při autocommit odkudkoliv, při použití transakce, spolehlivého databázového stroje a vhodně nastavené isolation level pak alespoň uvnitř probíhající transakce.

To platí, že se změny povede zapsat na disk - MyISAM ale používá file systémovou cache, a v případě havárie se změny vůbec nemusí promítnout do datových souborů, nemusí se stihnout zapsat nic nebo jen něco - to už je záležitost operačního systému. Transakční systém není jen atomičnost a izolace, ale také Durabiilty -- garance, že jsou změny bezpečně zapsané - a to MyISAM také nemá.

377

Server / Re:Porovnání SQLite vs. MySQL

« kdy: 18. 09. 2016, 15:16:58 »

MySQL umožňuje používat různé databázové enginy – např. MyISAM transakce nepodporuje, InnoDB je podporuje. Nevidím jediný důvod pro použití MyISAM.

Nevím, jaký měl autor aplikace důvod pro použití myisam. Zaráží mě ale, že v té databázi je komponenta, u které se nelze spolehnout, že se provede update. Hlásil tu chybu někdo autorům? Pokud ano, proč je tam ta chyba pořád?

MyISAM je v MySQL default. Pokud chceš jiný engine, musíš to té databázi říct. Autor aplikace to neudělal.
...
Autoři MyISAM nám maximálně doporučí, abychom přešli na InnoDB, protože se tím už nechtějí zabývat. Ostatně tohle doporučení zde bylo zmíněno již mnohokrát.

Je tam více enginů, jako výchozí je nastavený ten s chybami a autoři už se tím nechtějí zabývat? Ale fuj! Nechce se mi věřit, že je na tom MySQL skutečně až tak špatně. Pořád bych byl ochotný věřit, že šlo o nějaké špatné sestavení v Debianu, že byl špatný driver v Perlu, ale proč by někdo nastavoval jako výchozí engine takový, který funguje špatně?

To, že MyISAM nepodporuje transakce není chybou - tak byl navržen - a díky tomu řada operací byla rychlá i na slabých 386kách a 486kach (taky důvod, proč se MySQL začal tak masivně používat a důvod, proč jsou některé operace na MySQL rychlé). InnoDB je snad od MySQL 4.0 ?? cca 15 let. Tuším, že posledních 5 let je i default. Tady MySQL šlo na ruku vývojářům, kteří chtěli něco rychlého. To, že nezmigrovali na InnoDB, to fakt není vina MySQL.

Tady měl a má Postgres velkou výhodu - nikdy se až tak moc nepodbízel (nikdy nebyl komerční), a mantrou nikdy nebyla rychlost, ale spolehlivost. Takže Postgres si oblíbili uživatelé, kteří upředňostňovali spolehlivost (a nepotřebovali hosting), pro ostatní webaře tu pak byl MySQL - hlavní bylo, že běží na hostinzích - a od samotné db se snažili, co nejvíc, se izolovat.

378

Server / Re:Porovnání SQLite vs. MySQL

« kdy: 17. 09. 2016, 19:03:05 »

Jestli se používal MyISAM engine, tak není co řešit - ten transakce vůbec nepodporuje! Tudíž to, že po havárii jdou data přečíst je jen příjemná (nicméně negarantovaná) vlastnost. Fakticky netransakční engine (jako je např. MyISAM) vůbec negarantuje stav dat v případě havárie. To, že to programátoři zvesela používali, jen ukazuje jejich nevelké znalosti a nulovou odpovědnost.

Firebird transakce má a u nás po havárii většinou dopadne hůř než MyISAM.

A nemáte vypnutý  fsync? Pokud se fsyncuje, tak zrovna Firebird měl být ok

379

Server / Re:Porovnání SQLite vs. MySQL

« kdy: 17. 09. 2016, 17:02:27 »

Tohle rozhodně není běžné chování MySQL. Nikdo by ji nepoužíval. Zdroj chyby může být kdekoli - od chyby HW, přes chybu konfigurace až po chybu v sestavení dotazu.

Ze kterého jazyka pocházel ten SQL dotaz? Který databázový ovladač byl použit? Byla databáze na localhostu nebo mimo?

Taky si myslím, že tohle není normální. Do databáze se sypala data z perlu. Databázový ovladač... nevím - je to podstatné, když nefungoval ani update z povelové řádky? Databáze na localhost. Čtení dat z php (pouze čtení). Transakce vyloučené (myisam, programátor transakcemi netknut). Hardware bych taky vyloučil, neprojevovalo by se to na tolika strojích a po kompletním přepsání aplikace ty stroje fungují dodnes. Z dnešního pohledu odhaduji, že mohlo jít o nějaké špatné sestavení nějaké speciálně vybrané prehistorické verze MySQL v Debianu. Stálo mě to jen spoustu nervů a vysvětlování, proč by se měla aplikace zahodit a pořídit jinde (aplikace byla odpad i z mnoha jiných hledisek). Každopádně tenhle incident důkladně prohloubil moji nedůvěru v MySQL.

Tak tohle vypadá na chybné použití databázového ovladače v Perlu. Vzpomínám si, že jsem kdysi dlouho hledal, proč mi MySQL neukládá data posílaná z Pythonu. Na vině bylo chybějící volání cursor.commit(), ačkoli jsem žádnou transakci neotevíral. Teď už to vím, protože mě to vyškolilo. Také vím, že při práci s databází se toho dá hodně pokazit.

Používání MyISAM se dnes už moc nedoporučuje, de facto k tomu ani není důvod. Vždyť ani pořádně neumí transakce. InnoDB je úplně jiný level. Nijak však nevylučuji, že se pro danou úlohu může hodit jiná databáze, např. SQLite ši PostgreSQL. Často bývá potřebný větší rozbor.

Jestli se používal MyISAM engine, tak není co řešit - ten transakce vůbec nepodporuje! Tudíž to, že po havárii jdou data přečíst je jen příjemná (nicméně negarantovaná) vlastnost. Fakticky netransakční engine (jako je např. MyISAM) vůbec negarantuje stav dat v případě havárie. To, že to programátoři zvesela používali, jen ukazuje jejich nevelké znalosti a nulovou odpovědnost.

380

Studium a uplatnění / Re:Jaký je stav v IT teď a výhledově do budoucna co se týká schopných lidí?

« kdy: 08. 07. 2016, 07:33:04 »

Čulíka sice moc nemusim, ale tahle debata mi příde zajímavá:
Debata s Janem Čulíkem o školném
https://www.youtube.com/watch?v=BsQmdwgnxWA

Jak už tady někdo vzpomenul, jak to udělat, aby se nerušily obory které nemají okamžité uplatnění a týká se to i té vaší oblíbené matiky. Různé teorémy, postupy najdou uplatnění až třeba mnoho (desítek) let poté, co byly vynalezeny.
Zabránit tomu, aby se ze škol nestaly fabriky na peníze.
Uvědomuje si vůbec někdo, že když taková škola dá přednost bohatýmu Arabákovi nebo Číňanovi před domácíma, tak tím si vlastně sami na sebe vychováváme konkurenci?
Já osobně nejsem apriori proti školnýmu. Ale ať je to kompenzováno třeba tím, že se sníží daně, protože samozřejmě když to nebude placeno z daní, tak se mohou snížit. Ať má navíc ještě takový absolvent pár let po studiu další daňové úlevy.

Komerce potřebuje reklamu a reklama potřebuje osobnosti, tedy v případě vysoké školy, osobnosti a obory ze základního výzkumu. Za školu kde učí samí praktici nikdo platit nebude, bude mu chybět nimbus výjimečnosti, který škole dají jen nepraktičtí teoretici. Školy budou mezi sebou konkurovat, a v konkurenčním boji nezvítězíte pomocí nějakých šedých myší, ale právě díky osobnostem. Viz třeba komerční sport, který takové osobnosti vyrábí uměle, pomocí médií, aby se lépe prodával. Svět je dokonalý. Vysoké školy vznikly díky snaze soustředit takové osobnosti na jedno místo, ke chvále panovníka. Vzdělání byla až sekundární motivace.

Idealista nebo bl.ec? Teď lituju, že na tu není podobný systém jako na abclinuxu, který umožňuje blokovat externality.

381

Vývoj / Re:Funkcionální jazyky.

« kdy: 21. 08. 2015, 09:56:55 »

...Jakmile pomatenci začali OOP zneužívat na modelování reálného světa tak to nutně muselo skončit obrovským průšvihem, protože OOP na to nikdy nebylo stavěné a také se tak stalo Čili problémem není OOP, ale nerealistická očekávání od OOP, OOP je mírná evoluce procedurálního programování, žádný megahyperzázrak, spasení lidstva a záchrana Pandy Velké

Tak, a ještě horší situace nastává, když se OOP (resp. OOP se třídami) začne násilím roubovat na jiná paradigmata. Už jsem vidět šílené (relační) DB schéma navržené "objektově", to byl dobrej humus. Asi 300 tabulek pro zcela jednoduchej use case atd. atd. Jen proto, že se někdo od Javy nechtěl "špinit" s SQL :-)

Jo, bohužel tohle je tragická realita - kolikrát nechápu, kde se v systému objevují stovky tabulek, a proč dotazy obsahují desítky joinů - a pak ORMka dávají logiku - při silně neprakticky navrženém schématu databáze se fakt SQLka píší špatně - a potřebujete ORMko, jinak se z toho zblázníte. Při návrhu relační databáze je potřeba zapomenout na dědičnost - jinak je to neštěstí.

382

Software / Re:Program pro stažení celého webu

« kdy: 25. 07. 2015, 20:47:59 »

... Skripty pro výpočet jsou uloženy kdoví kde na webu a to v rámci stahovačů není možné. ...

A nešlo by nějak stáhnout všechny soubory z té adresy, ať už k nim cesta ve zdrojovém kódu stránky vede nebo nevede?

Pokud nevíte, jak se ty soubory jmenují, tak to z principu nelze.

383

Studium a uplatnění / Re:Deník nasraného studenta

« kdy: 11. 07. 2015, 16:57:46 »

To uz tak byva, ze hlupaci si mysli, jak jsou chytri.

to je fakt

384

Vývoj / Re:Je Pascal mrtvý jazyk?

« kdy: 10. 07. 2015, 18:11:33 »

Nedávno jsem potkal nějakou open-source aplikaci dělanou Lazarem. V distribučních repozitářích to není, protože balení je noční můra. GUI hnusné. Jazyk samotný…

…mno, na učení to moc není, protože chybí interaktivita – furt překládat kvůli překlepům (jako packalovská středníková konvence) je demotivující. I jako pseudokód je podmnožina Pythonu čitelnější. Ani o hardwaru se toho člověk zase tolik nedozví ve srovnání s Céčkem.

To je v rukách - ne v jazyku. Je to jazyk, který byl navrhovaný pro jinou dobu a jiné počítače, a jiné lidi. Pro základní algoritmizaci je pořád super.

385

Vývoj / Re:SQL select

« kdy: 07. 07. 2015, 19:52:56 »

* Zdanlivou nevyhodou tohoto pristupu je, ze se data musi vejit do pameti. Pokud ale ma byt DB svizna, musi splnovat stejny pozadavek.

Jenomže relační databáze pracuje s pamětí výrazně efektivněji - a pokud jí paměť dojde, tak při dobře navrženém schématu neztratí výkon fatálně - resp - celá ta technologie je navržena tak, aby fungovala i s relativně malou pamětí - samozřejmě, nesmíte používat EAV.

386

Vývoj / Re:SQL select

« kdy: 07. 07. 2015, 15:29:24 »

No dobře, to je určitě pravda. EAV je snaha ukládat data s proměnnou strukturou do databáze s neměnnou strukturou. Pak jsem odkázán na to, že sémantiku uložím jako hodnotu. Na druhou stranu se s tím člověk setká opravdu často, skoro v každé databázi, se kterou jsem se setkal, je pár takových tabulek. Jsonb nebo Hstore by pro nově navrhovanou databázi byly asi ideální, akorát nevím, jaká je podpora v ORM nástrojích? Můžete doporučit nějaké zdroje k tomu? Zajímá mě hlavně java.
Uvítám nějaké zdroje k výše řečenému.

Javě a ORM se vyhýbám obloukem, takže o nich nic nevím. V tuhle chvíli jsou Hstore i Jsonb dost jednoduché typy, které podporují základní operace, a jejich jediná výhoda je, že drží efektivně atributy pohromadě. Pro Jsonb se připravuje několik extenzí, které výrazně zvýší možnost dotazování - http://pgxn.org/dist/jsquery/1.0.0/ a o podpoře schémat (zatím jsou to spíš pokusy https://github.com/petrounias/json-schema-toolkit ) už jsem také slyšel (zatím je k dispozici validace pomocí contraintů a výrazů http://blog.endpoint.com/2013/06/postgresql-as-nosql-with-data-validation.html). Hstore se už rozšiřovat nebude - je to předchozí generace Jsonb

387

Vývoj / Re:SQL select

« kdy: 07. 07. 2015, 12:34:11 »

...
nicméně dobré řešení asi neexistuje - způsob jaký používáte se označuje jako EAV a je to známý antipattern - taky proto se Vám s tím špatně dělá.
...

Dlouho jsem s DB nic pořádného nedělal, ale zajímá mne to:
Pavle, co je v tomto případě ten antipattern?
Struktura té tabulky?
A pokud ano, jak by se to mělo řešit správně (mne teď v těch hicech nic nenapadá + viz výše), stačí třeba jen nějaký link na něco k přečtení ...

Relační databáze předpokládají, že význam je určený sloupcem - mám sloupec příjmení, mám sloupec jméno. Jakmile se sémantika určuje další hodnotou, nebo několika dalšími hodnotami, tak SQL jako celek přestane fungovat - dotazy přestanou být názorné a čitelné, odhady založené na statistikách budou ustřelovat - a z SQL databáze se stane polofunkční key/value databáze - protože celý ten aparát - SQL, optimalizace, exekuce je navržená na nějaký způsob uložení dat, a pro něj je 30 let optimalizována.

Jak by se to mělo řešit správně - předně, musím si uvědomit, co chci dělat - pokud pracuji s extrémně dynamickými daty, které za pár týdnů zahodím, tak bych asi nepoužil relační databází, ale šel bych do NoSQL databáze - relační databáze, jsou navržené tak, aby dokázaly rychle zpracovat velké množství dat se stabilní strukturou - evidence, sklady, řízení výroby. Pokud ale stabilní strukturu nemám - pracuji s velkým množstvím dynamicky měnících se atributů - vyhledávání v katalogu produktů, atd - tak bych měl použít dokumentovou databázi, která je postavená úplně jinak, a na jiný typ dotazů. EAV je snaha o napsání si vlastní dokumentové databáze - bohužel už je to nad SQL databází a tam už programátor nemá možnost to udělat efektivně.

Pro projekty, které nejsou velké asi budou postačovat extenze do stávajících relačních databází, jako je v Postgresu Jsonb, Hstore, které částečně umožňují kombinovanou práci. U velkých projektů (desítky, spíš stovky GB) je výhodnější použít víc specializovaných databází - finance, majetek řeším v relační SQL db, vyhledávání v katalogu v NoSQL databázi, a cache řeším nějakou paměťovou databází, analytiku pak sloupcovou. Jednak se mi dekomponuje prostředí, druhak díky použití optimalizovaných databází a jazyků nemusím vymýšlet desítky berliček a workaroundů, a každý blok pak je výrazně jednodušší a čitelnější. Nelze si vystačit jenom s jedním stylem - protože jdou proti sobě.

388

Vývoj / Re:SQL select

« kdy: 07. 07. 2015, 11:34:14 »

Asi jsem dostatečně nezdůraznil, že uvedené možnosti byly pouze příklady, a potřebuji obecnější postup. Jde o to, aby si podmínku vytvořil v jednoduchým klikátku uživatel, který má k dispozici tlačítka "přidat vlastnost" "AND" "OR" "(" a ")" - mohl si naklikat cokoliv, třeba "(A and (B or C) and (D or E)) or G" - prostě cokoliv. Takhle naklikaný výraz potom jednoduše sparsuju PHPčkem do query, který použiju na to view, který jsem si vytvořil.

A ano, uznávám, s SQL nepracuju, spíš ho občas používám.

Jinak mám to sice vyřešený, ale jestli někdo přijde s nějakým elegantnějším řešením, tak ho určitě uvítám

Elegantní řešení na relační databázi neexistuje - z principu - to, co děláte prostě relační databáze nedělají. Můžete zkusit nerelační databázi - CouchDB, MongoDB, ElasticSearch - a tohle tam bude triviální - případně v Postgresu použít uložení do HStoru a dotazovat se nad HStorem (což je tak v podstatě už nerelační uložení dat).

389

Vývoj / Re:SQL select

« kdy: 05. 07. 2015, 17:24:08 »

Sice se mi to zda porad nejaky prekombinovany a mozna bude existovat jednodussi metoda, ale takhle je to na tech par tisic radku co resim i docela rychly a hlavne to skladani podminek funguje bezvadne.

Ono nejde o to, ze to je překombinované, ale na větších datech to by to bylo asi i dost pomalé - je tam jednak skládání stringu, a potom vícenásobný LIKE. Pro pár tisíc řádek to nepoznáte, ale pro víc než desítky tisíc to může být dost špatné - nicméně dobré řešení asi neexistuje - způsob jaký používáte se označuje jako EAV a je to známý antipattern - taky proto se Vám s tím špatně dělá.

Obvyklé řešení je založené na vícenásobném selfjoinu, které by mělo být docela rychlé pokud podmínkám bude odpovídat tak do 3% řádků. Potom už asi může být rychlejší scan s HAVING.

390

Server / Re:Výpočet potřebného výkonu stroje pro DB

« kdy: 02. 06. 2015, 10:22:27 »

Po pár iteracích pak máte aplikaci, která drží roky. Samozřejmě nesmíte udělat zásadní návrhové chyby - to se pak po pár letech přijde na to, že je to pomalé a kromě totálního přepsání se skoro nic moc nedá dělat.