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

XCHAOS: errrr.... nezapomel?
Takze ten bottleneck vidis na strane skladani dotazu, ne na strane SQL serveru?

XCHAOS: tak opravím tu větu "nemyslím si, že jediný možný směr vývoje od C je k C++ nebo Objective C" - spokojen - ne. Debata byla o tom, ze Cll1 je pitomost s celou radou problemu na mnoha ruznych urovnich. Ne o nejakych smerech vyvoje, to si dost fandis 8))

XCHAOS: dobře oindexovanou tabulku, která se navíc celá vejde do paměti, je databázový stroj schopen prohledat velmi rychle - pokud pouzivas SQL databazi abys prohledaval oindexovanou tabulku ktera se vejde do pameti, navic v situaci kdy ti tolik zalezi na vykonu ze si nemuzes dovolit rozparsovat SQL prikaz, tak delas neco hodne blbe. Coz asi nikoho neprekvapuje 8))

REDGUY: dobře... tak opravím tu větu "nemyslím si, že jediný možný směr vývoje od C je k C++ nebo Objective C" - spokojen?

(a ne - odpověd "používej místo C vyšší programovací jazyk" mě taky nevyhovuje - mě zajímá používat C takovým způsobem, jakým já sám uznám za vhodné... a většina open source aplikací napsaných v C jde touto cestou, BTW)

REDGUY: jo a ne... dobře oindexovanou tabulku, která se navíc celá vejde do paměti, je databázový stroj schopen prohledat velmi rychle... a nedělám si iluze, že bych sám dokázal napsat něco, co by se vyrovnalo databázovým enginům vyvíjeným po celé generace. jinými slovy: vyjímečně netvrdím, že jsem já sám schopen naprogramovat něco lépe, než někdo jiný :-) zajímám se jen o API k něčemu již hotovému.

vím, že existuje třeba toto http://www.sqlite.org/ - http://www.sqlite.org/faq.html ... ale nevím, jestli je to úplně přesně to, co mám na mysli já.

XCHAOS: není to trochu overhead? - neni. Jako obvykle se snazis optimalizovat na spatnem miste. Jo, parsovani dotazu chvilicku trva. Ale ve srovnani s tim, co trva jeho nasledne provedeni, je to v podstate nula nula nic.

celkově jsou databázové servery zatížené výrazně méně, než webservery - wut? A co je zase tohle za pitomost? Na to jsi prisel jak?

XCHAOS: No a? To nic nemeni na tom, ze nikdo nerikal ze " jediný možný vývoj od C směruje k C++". Naopak, snazili jsme se ti ukazat spoustu jazyku, ktere ukazujou jinou cestu - viz treba to Objective C. To ze tyhle doporuceni ignorujes je tvuj problem.

DAVIDOWITCH: no, pokud máš jednovláknovou jednouživatelskou aplikaci, tak jistě... celkově jsou databázové servery zatížené výrazně méně, než webservery (což je pro mě nejdůležitější důkaz toho, že se dnes prostě programuje špatně)

víceméně - zapomněl si, že já se o C zajímám výhradně proto, že chci psát jiné, než jendouživatelské desktopové aplikace (u kterých je vlastně jedno, jestli klient počká 5 sekund nebo 10 sekund a mezitím rád zkoukne nějakou duchaplnou animaci, apod.)

XCHAOS: Tipl bych si ze parsovani toho stringu je v ramci slozitejsiho dotazu naprosto zanedbatelny, ne? (as in "nemeritelny")