FLEGMA: viz to co jsem psal: já bych se ani nebránil vygenerování té C-syntaxe z konvenčního textového SQL dotazu: dokonce by na to určitě šlo udělat nějaký markup, který by ti zdroják před-kompiloval, pokud by si změnil ty SQL dotazy v nějakém specificky naformátovaném "komentáři", předcházejícím generovanou sekvenci (prostě zase makra, akorát tentokrát na jiném levelu :-)

že se to používá, jsem tušil.. před lety jsem si vyměnil pár mailů s Ondřejem Čadou, který si mi vytahoval tím, že jeho úžasný C++ framework umí právě tohle (akorát si nejsem jistý, jestli jen pomocí přetěžování C++ operátorů neřetězil ten SQL dotaz - ale to zřejmě právě bylo jednotné API pro různé implementaci)

vlastně celý můj dotaz byl "existuje něco takového např. pro MySQL"? protože protlačování výsledku přes sockety to zase může (trochu brzdit) - pokud by to byla databáze ve sdílené paměti (v tomto jsou Unixy/Linuxy dobré a já jsem v používání shmget() začátečník), tak pochopitelně: výsledek dotazu pak může být složen z pointerů na původní umístění v paměti a nic se nemusí kopírovat.

DAVIDOWITCH: jo a ne. hele, já sice pokládám C-zdroják za slušný "základní level" visualizace, skrze který si prohlížet "co se děje uvnitř" (rozhodně nejsem nadšenec pro nějaké binární výpisy, disassemble, apod. - to je prostě už moc "pod zemí", pro mě, když bych se v něčem takovém musel hrabat... je to pro mě fail asi jako když macintoshista musí sáhnout na něco jiného než myš a tlačítko jabko na klávesnici). Ale vůbec netvrdím, že všechen C zdroják musí být napsaný ručně: sám pracuju např. na generátoru C zdrojáků z HTML šablon... a existuje spousta jiných nástrojů, co něco generují.

např. GIMP umožňuje uložit ikonky ve formě C zdrojáku, existují parsery syntaxe, které generují C procedury on fly, apod. - mě by vůbec nevadilo, kdybych měl nějaký nástroj (např. commandline, či na webu), do kterého bych napsal normální SQL dotaz, a ono by mi to (na stdout, do clipboardu nebo tak) vygenerovalo sekvenci těch C procedur, které dělají s datovou strukturou to samé. já vůbec nejsem odpůrce generovaného zdrojového kódu!

JACHYMKO: no víceméně si docela nastínil, jak si takové C API pro SQL představuju :-) (i když samozřejmě, šlo by to jistě vylepšit několika dobře promyšlenými makry preprocesoru)

hele, tohle není o tom, aby to bylo user-friendly... pokud někdo píše dotazy přímo v SQL, tak nejspíš stejně frontend napíše taky v nějakém vyšším jazyce. ber to třeba tak, že se snažím o cosi jako "sportovní výkon" - soustředit co nejvíce lidí na serveru u mě doma nebo prostě aspoň na mém osobním serveru ("na BBSce", chceš-li ... či na IRC, cokoliv) a s co největším uživatelským komfortem (odpovídajícím téhle době) i s pokud možno realtime odezvou.

samozřejmě ti může připadat víc cool mít to celé hostované na nějaké serverové farmě... ale to je jako srovnávat nějakou sportovní událost s jízdou vlakem.

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.

REDGUY: Děkuji.

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))

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).

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?

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ě? :-)

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.

FLEGMA: Ano. V podstatě mluvím o "neobjektovém relačním mapování" :-)

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...)

FLEGMA: Ja sem pochopil ze nechce generovany SQL dotazy, ale chce nejak predzpracovany SQL dotazy aby pak ten samotnej dotaz byl rychlejsi.

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.

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))