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

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.

REDGUY: Muzete alespon naznacovat?
(Mne to prekvapilo protoze ted nevlastnim pocitac co by mel alespon 8GB)

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

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

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

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.

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?

XCHAOS: Tos me s tou prenositelnosti nepochopil. Ja nemyslel ze to nepustis na jinym stroji ale ze to nepustis proti jiny databazi.

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)

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.

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

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?

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

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.

REDGUY: tak pro začátek jsem to přejmenoval na crl1.h :-) a budu to od základu překopávat tak dlouho, až to pitomost být přestane. to je celé.

DAVIDOWITCH: to jsem neřekl :-) dostatečně promyšleně špatně navržené SQL tabulky a současně necacheovatelné SQL dotazy dokáží divy :-)

jsem jsem říkal, o co já se to vlastně celá léta snažím, když navrhuji sám nějakou datovou strukturu - o cosi jako "předkompilovaný SQL dotaz", přece. takže v podstatě ano.... když už vytvářet vlastní datové struktury, tak proč neuvažovat tak, aby z nich šlo předkompilovat celé SQL dotazy?

nad tím, že se třeba regulární výrazy kompilují, se nikdo nepozastavuje. to o čem mluvím, je sice trošku složitější problém... ale v podstatě... proč by to nemělo být možné? u nejprimitivnějšího dotazu je toto téměř triviální... ale bavíme se pochopitelně konstrukcích typu JOIN, GROUP BY, apod.

když dnes přemýšlím o libovolném problému - at už jde o firmu nebo o soukromé projekty, tak to většinou vede k návrhu nějakých vzájemně provázaných tabulek - a naopak málokdy to vede k návrhu nějaké třídy objektů, které by od sebe vzájemně něco dědily... (to možná ještě ty pohledy na data by šlo nějak rozkouskovat do těch tříd...)