• ú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 --- ---
    2 odpovědi
    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 --- ---
    2 odpovědi+1
    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 --- ---
    2 odpovědi+1
    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 --- ---
    1 odpověď-1
    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 --- ---
    1 odpověď
    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 --- ---
    -1
    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 --- ---
    2 odpovědi
    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 --- ---
    2 odpovědi
    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 --- ---
    3 odpovědi
    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 --- ---
    1 odpověď
    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 --- ---
    1 odpověď
    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 --- ---
    1 odpověď
    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 --- ---
    1 odpověď
    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á)
    Kliknutím sem můžete změnit nastavení reklam