• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    XCHAOSANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    FLEGMA: Kdyz mne furt prijde ze ty mu nabizis pohodlnejsi a "silnejsi" vyrobu dotazu, kdezto xchaos touzi po rychlejsim zpracovani (tj. mit to ze strany stroje co nejvic predzvejkany). Takze dynamicky skladani jde primo proti tomu po cem touzi.
    FLEGMA
    FLEGMA --- ---
    XCHAOS: Presto bych ti doporucil skouknout kod nejakyho ORM frameworku, protoze to, co se snazis vymyslet, uz davno existuje. Mapovani SQL na datovej model fakt neni novinka dnesniho roku :-DD. A to jak predpripraveny dotazy, kdy mas nejakej string jako:

    select title from blog b where b.id = :idParam

    a pak uz dynamicky v kodu jen nasetujes ten parametr nebo druhej zpusob popsal JACHYMKO, kdy mas nejaky api na pridavani podminek, projekci (ktery sl. se vyberou), joiny, razeni, atd. a skladas dotaz kompletne dynamicky. Oba dva zpusoby se v ORM frameworkach pouzivaj. Chapu, ze tvuj model neni objektovej, ale muzes trochu popsat usecase (vcetne typu dat, jestli to neni tajny) pro tvuj toolik, pak pujde treba lip pochopit, proc chces sesmolit neco vlastniho.
    CHEVALIER
    CHEVALIER --- ---
    REDGUY: Děkuji.
    REDGUY
    REDGUY --- ---
    CHEVALIER: Nikde nemluvim o pristupu k _databazi_ jinak nez pres SQL (ovsem i to samozrejme jde, viz NoSQL databaze). Mluvim o pristupu k datum. Kdyz mam data ktera se mi vejdou do pameti a ke kterym budu potrebovat pristupovat tak casto a tak rychle, ze i parsovani SQL prikazu bude problem, tak ty data nebudu drzet v SQL databazi na jinem serveru (nebo aspon v jinem procesu), ale proste je budu mit rovnou u sebe v pameti a budu k nim pristupovat primo. Nebudu muset resit sitovou latenci, parsovani SQL, to ze databaze je delana na genericky data takze jeji query optimizer nemusi najit optimalni strategii pro muj konkretni pripad a tak dale.
    CHEVALIER
    CHEVALIER --- ---
    REDGUY: Jsem neznalec. Jak se dá přistupovat k databázi jinak než přes SQL. Jde mi konkrétně o SQLite3. Děkuji.
    REDGUY
    REDGUY --- ---
    Hele, vis co, XChaosi? Je to prece jednoduchy. Mame tendlecten opensource, tak vezmi svoji oblibenou databazi, pridej do ni logovani jak dlouho trvalo rozparsovat kazdej dotaz a spust nejakej real-world test a pak se pochlub cislama. Ciny misto kecu! Oh, wait... ja mluvim s xchaosem 8))
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: 100x nic umorilo osla by davalo smysl, pokud bys 100x parsoval na 1 dotaz. Pokud ale 100x parsujes na 100 dotazu, tak ti to parsovani furt dela nejaky naprosto nezanedbatelny procento casu (tipl bych ze dost pod varianci v pingu).
    REDGUY
    REDGUY --- ---
    XCHAOS: jenže 100x nic umořilo osla... jak rikam: pokud mas data, ktera se (a) vejdou do pameti a (b) pristupujes k nim tak casto, ze i ta odhadem radove milisekunda (mozna mene) parsovani SQL je kriticka, tak jsi idiot pokud k nim pristupujes pomoci SQL. Chapes?

    Btw, uz ti doslo jaky je rozdil mezi SQL a RE, diky kteremu ma smysl RE predkompilovat, zatimco SQL ne?
    REDGUY
    REDGUY --- ---
    XCHAOS: jde o to, že já směřuju k decentralizované síti malých serverů coz ten google v podstate taky, ze. Podle vsecho maji velmi mnoho relativne malych pocitacu.

    pokud tebe živí centralizace, tak už chápu, proč je pro tebe tak existenčně důležité se mi posmívat...) - HAHAHA. To je fakt super jak hrozne si fandis. Opravdu si myslis, ze i kdyby nahodou me zivilila centralizace (nezivi), tak pro moji existenci je nejak podstatne jestli se zrovna tobe posmivam? Ne, fakt nejsi tak dulezitej.
    XCHAOS
    XCHAOS --- ---
    koukám... "sledujících lidí 78"... nemělo by to tu aspon trochu víc být o Céčku a o Linuxu, v takovém případě? :-)
    XCHAOS
    XCHAOS --- ---
    REDGUY: jenže 100x nic umořilo osla... a opět, pokud sis nevšiml, tak interakce uživatel vs. server se za posledních 10-15 let posunula daleko více k realtime, než tomu bylo historicky.

    pokud bych psal skript, co se pustí jednou za den v 6 ráno z cronu, tak mi pochopitelně bude srdečně jedno, jestli poběží 5 sekund nebo 50 minut. ale pokud píšeš nějaký ajaxový onmouseover, tak ti najednou není jedno, jestli se každý request na server zpracovává desetinu sekundy.
    XCHAOS
    XCHAOS --- ---
    FLEGMA: Ano. V podstatě mluvím o "neobjektovém relačním mapování" :-)
    XCHAOS
    XCHAOS --- ---
    FLEGMA: jestli myslíš http://cs.wikipedia.org/wiki/Objektov%C4%9B_rela%C4%8Dn%C3%AD_mapov%C3%A1n%C3%AD tak je to možná přibližně, ale ne zcela přesně to, o čem asi mluvím.

    pro mě je to prostě "compile time SQL" :-)

    REDGUY: jo, sice se hádáme už asi 3 roky, ale postupně se poznáváme. já investory rád nemám a z peněz investorů nežiju (no, samozřejmě diskutabilně... když podepíšeme s dodavatelem smlouvu na X let a on si půjčí peníze, aby danou službu zřídil...).

    jak je přesně implementovaná serverová farma Googlu, to popopravdě ví málokdo - a já už vůbec ne. jde o to, že já směřuju k decentralizované síti malých serverů - do prostředí heterogenního, co se administrace týče (ano... pokud tebe živí centralizace, tak už chápu, proč je pro tebe tak existenčně důležité se mi posmívat...)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    FLEGMA: Ja sem pochopil ze nechce generovany SQL dotazy, ale chce nejak predzpracovany SQL dotazy aby pak ten samotnej dotaz byl rychlejsi.
    FLEGMA
    FLEGMA --- ---
    XCHAOS: No ty se vlastne ptas po ORM frameworku. V Jave je nejkomplexnejsi Hibernate, ekvivalent pro C++ by mel bejt LiteSQL a Hiberlite, ale to jsem nezkousel. ORM je idealni na CRUD operace, naopak na high performance, masivni zpracovani dat je logicky lepsi rucne psany SQL nez generovany, kvuli specifikam optimalizace v db enginu (napr. hinty v oraclu) Da se to i kombinovat, cast dotatazu generovat a performance critical sql mapping dopsat rucne.
    REDGUY
    REDGUY --- ---
    XCHAOS: ne každý rozhazuje peníze investorů - HAHAHAHAHAHA. Jojo. Jezis, to je tak _strasne_ vtipny, s ohledem na to jak peclive nas nasi investori kontrolujou (a jak jsou zatim spokojeny).


    XCHAOS: se v současnosti horečnatě snaží rozvíjet svůj vlastní "9824345. blgoovej engine" - jo, jasne. A povidej, prehanej, jak jsou zatizeny jejich DB servery? A jak jejich www servery? A jak se jim data vejdou do pameti serveru se 4GB ram? Povidej, kdyz o tom tak sebejiste vykladas, urcite o tom spoustu vis. Sem s tim 8))
    REDGUY
    REDGUY --- ---
    XCHAOS: proto se ptám na to, jestli je to nějaké API, že ano je. A jmenuje se SQL. A pricetni lide vedi, ze parsovani SQL prikazu trva nula nula nic a nema smysl ztracet cas nejakou pseudooptimalizaci.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    REDGUY: Muzete alespon naznacovat?
    (Mne to prekvapilo protoze ted nevlastnim pocitac co by mel alespon 8GB)
    XCHAOS
    XCHAOS --- ---
    REDGUY: popravdě - i Google, jako největší serverová farma na světě, se v současnosti horečnatě snaží rozvíjet svůj vlastní "9824345. blgoovej engine" (protože nic jinýho GooglePlus není, že ano...). v podstatě ano - je to dnes stejně základní zadání, jako byl před 30 lety WYSIWYG textový editor.

    (viz tag #whitespace, že ano :-)
    XCHAOS
    XCHAOS --- ---
    REDGUY: dobře, ale každý nepracuje v Seznamu, nebo kde. a většina firem má poměrně příčetné požadavky na množství dat svých klientů, se kterými pracuje (rozuměj: ne každý rozhazuje peníze investorů - někdo hospodaří jen s tím, co sám vydělá)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no... ano. ne. proto se ptám na to, jestli je to nějaké API, že ano :-)

    prostě to, nad čím si lámu hlavu je jednoduché: jak kdo vlastně programuje složitější datové struktury do svých aplikací jinak, než že naformuluje SQL dotaz do stringu a zavolá nějaké spojení do databáze? viděl jsem pochopitelně ledacos... ale zase proti tomu, co jsem si zvykl používat za funkce v SQL, je to všechno poměrně primitivní...
    REDGUY
    REDGUY --- ---
    XCHAOS: prostě mě překvapilo, kolik (nejen mého) zdrojového kodu je (zejména u webových aplikací) tvořeno věčným skládáním SQL dotazů - no samozrejme, pokud to co programujes je 9824345. blgoovej engine, kde se veskera logika omezuje na "vyber post z databaze, aplikuj templatu a posli userovi" a navic nejsi schopen pouzit nejakej rozumnej framework pro pristup k db, tak neni divu ze znacne procento kodu tvoji sestavovani sql. Jednak si ale neplet pocet radek kodu s casovou narocnosti, jednak negeneralizuj svoje sudlani blogenginu na programovani obecne.
    REDGUY
    REDGUY --- ---
    XCHAOS: budeš se divit.. ale v dnešní éře serverů s 4GB paměti (a více) - HAHAHAHAHAHAHAHAHAHA. Jezis, to je roztomily. Opravdu me velmi mrzi, ze ti nemuzu rict kolik serveru ve firme provozujeme a kolik desitek giga rameti kazdy z nich ma, ale ver mi, tvoje recicky o "ere serveru se 4GB pameti" na me diky tomu moc nefungujou 8)))

    se naopak málokomu podaří naplnit databázi tolika daty, že se do paměti nevejdou - no a? Co to meni na tom, ze kdyz mas data ktery se vejdou do pameti a potrebujes k nim pristupovat sakra rychle, je _hloupost_ to delat pomoci SQL, bez ohledu na parsovani nebo neparsovani prikazu?
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Tos me s tou prenositelnosti nepochopil. Ja nemyslel ze to nepustis na jinym stroji ale ze to nepustis proti jiny databazi.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: v případě open source knihoven si tedy přenositelnost omezím jen stěží... prostě se vše doinstaluje všude, kde je to potřeba :-) (já jsem si schopen udělat apt-get build-essential i kvůli nativnímu místnímu překompilovaní nějakého pětiřádkového skritptíku v C.. ... .tohle je prostě způsob, jak to spousta lidí pod Linuxem dělá.

    když bych např. udělal ze své aplikace debianí balíček s dependencí na jiný balíček, tak se mi potřebná knihovna doinstaluje úplně na každém stroji, kde instaluji první balíček. (takhle prostě uvažuji já.... a už nechci svoje uvažování měnit směrem k nějakým proprietárním nepřenositelným binárkám)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: nevím. já jsem se jen zeptal...

    vím, že už léta existuje toto http://cs.wikipedia.org/wiki/Open_Database_Connectivity - ale přiznám se, že jsem se s tím nesetkal v jiném smyslu, než "existuje to". je to pokud to dobře chápu zase jen nějaký protokol.

    prostě mě překvapilo, kolik (nejen mého) zdrojového kodu je (zejména u webových aplikací) tvořeno věčným skládáním SQL dotazů. Samozřejmě - největší frajeři toto obalí nějakým abstraktně se tvářícím objektem - a navíc ještě ty dotazy skládají za pochodu i když to není nezbytně nutné, protože to pak vypadá "víc in")

    v podstatě ano - když už svojí aplikaci osudově provázat s nějakou knihovnou, tak v řadě případů by se menší databázový stroj hodil.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Huh? A to tuhle hyperoptimalizaci kde si podriznes portability vymenou za nejasnou-ale-spis-malou performance resis kvuli vecem co se vejdou na 1 server se 4GB pameti? To mi neprijde stastnej smer...
    REDGUY
    REDGUY --- ---
    XCHAOS: tak proč neuvažovat tak, aby z nich šlo předkompilovat celé SQL dotazy - protoze je to zbytecny, protoze je spousta prostoru optimalizovat jine veci, kde to naopak smysl ma.

    současně necacheovatelné SQL dotazy dokáží divy - a timhle myslis co? "necacheovatelne dotazy"?

    že se třeba regulární výrazy kompilují, se nikdo nepozastavuje - pochopitelne. Protoze je _sakra_ rozdil mezi RE a SQL. Schvalne, prijdes na to v cem ten rozdil spociva?
    XCHAOS
    XCHAOS --- ---
    REDGUY: budeš se divit.. ale v dnešní éře serverů s 4GB paměti (a více) se naopak málokomu podaří naplnit databázi tolika daty, že se do paměti nevejdou (samozřejmě... distribuované databáze v nějakých serverových farmách, to už je trochu jiné téma...)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Takze by si predhodil databazi kus dotazu, dostal zpatky nejakej neco, a pak se dotazoval timhle a k tomu prilepil nejakou blizsi specifikaci (hodnotu nebo tak). Takze by ses tesne navazal na konkretni databazovej stroj?
    Mas predstavu o pros a cons? Sem mel dojem ze cely kouzlo SQL je, ze kdyz ti prestane stacit MySQL tak tam hodis Oracle server a nemusis (i kdyz bys mohl a asi i mel) moc resit.
    Kliknutím sem můžete změnit nastavení reklam