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

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

jinak z jiného soudku... nevíte někdo nějakém "nativnějším" API k nějaké SQL databázi, než skrze.. ehm, jazyk SQL?

sám jsem tu postoval nějaké API týkající se libmysqlclient ... a moc se mi to líbí, je to snadné na použití, ale přeci jen: pokud budu za chodu programu vytvářet složitější SQL dotazy (jako stringy, naformátované podle konkrétní runtime situace - třeba doplnění čísla nějakého objektu, kategorie, rubriky, apod. do dotazu), a SQL server pak bude ty SQL dotazy zase parsovat... není to trochu overhead? neexistuje nějaké "nativnější" API k některé z běžných databází?

REDGUY: tenhle klub prostě vznikl jako reakce na můj ban v klubu o C++ ... to je celé.

v podstatě jádro kontroverze co tady proběhla, bylo, zda jediný možný vývoj od C směruje k C++ - to samozrejme zadne jadro nebylo. Resp. ukaz prosim jedinou zpravu, ve ktere kdokoliv tvrdi ze "jediny mozny vyvoj je od C k C++".

_BENNY: popravdě... na C se mi líbí fakt dost věcí (čehož důkazem je i tenhle klub), samozřejmě je tam i poměrně dost omezení - daných možná i tím, že v době vzniku tohoto jazyka se předpokládalo, že programátoři budou používat omezené zdroje tehdejších mini a mikropočítačů určitým tehdy nevyhnutelným způsobem (např. práce s pamětí, apod.)

v podstatě jádro kontroverze co tady proběhla, bylo, zda jediný možný vývoj od C směruje k C++ ... myslím nejsem jediný, kdo o tom pochybuje - viz např. jazyk D, ale ostatně třeba i Pythonisti si zjevně nemyslí, že všechny zdrojáky musí vypadat jako C++/Java, že ano..

FLEGMA: jinak s tou nezávislostí to není moc slavný.... jsem jen spolumajitel http://spoje.net (výhradní vlastnictví by mě dostalo maximálně do dluhů) a ta komunita kolem toho je dost živelná a spíše než nezávislost je nakonec prioritou vždy přeprodej něčeho, na čem se dá vydělat. nezávislost je spíš takový myšlený bod na horizontu... dobrý start je aspoň nepodnikat na základě úvěru, že jo.

FLEGMA: no... "neumět debugovat" vs. "neumět používat gdb" jsou dvě dost různý věci, řekl bych.

navíc z výraznějších věcí, který jsem v posledních letech někomu oddebugoval, nešlo nikdy o bug v céčkobé binárce - ale spíš o takové věci, že v browseru (teď myslím současný generický browser, než žádné historie) jakási věc skončí dřív, než by měla a utne tim jinou věc (různé javascript eventy, apod.) - popravdě, pár zajímavých / záhadných chyb jsem už v životě vyřešil, a s postupujícím časem jsem při tom méně a méně používal debugger.

pochopitelně - na řešení problémů při administraci unixu my programátoři prostě nemáme. viz včera, kdy se mi nedařilo po změně IP nahodit klientovi virtuální server, klient sice vyadoval noční zásah - ale naštěstí jsem odchytil celou sestavu firmy ve skladu, jak naráží sud Chýně, a jednoho našeho slibného junior admina/vývojáře napadlo zkrátit hostname (ne, že bychom tam neměli běžící servery s ještě delším hostname...). A ejhle... :-)