XCHAOS: já se ale nechtěl omezovat na datové struktury SQL - šlo mi vysloveně o to, že bych napsal jednořádkový SQL dotaz, který by mi pre-compiler rozexpandoval třeba na 10 řádků volání knihovních C funkcí - coze? To myslis vazne? Takze ty misto toho abys proste rucne napsal kod kterej bude pouzivat struktury, objekty, hashe, linked listy, stromy a janevim co jeste bude psat SQL ktery o nicem z toho nema ani paru a budes doufat ze optimizer to nejak zazracne vymysli? HAHAHAHAHAHAHA. Cim dal tim lepsi.

XCHAOS: což jsem u svých projektů elegantně chtěl řešit použitím makro-wrapperů, - HAHAHAHAHAHA. No nic.

norma POSIX se právě snažila striktně definovat i kompatibilitu hlavičkových souborů k běžným knihovním funkcím jo, a "bezne knihovni funkce" jsou plne a naprosto dostacujici pro real-world projekty.

Jen tak pro legraci, jak dobre by dneska fungoval tvuj slavnej prometheus kdybys ho napsal v roce 1994? (a nez napises nejakou pitomost, zamysli se nad tim, jak vypadaly linuxove firewally v roce 1994).

XCHAOS: jasně, že bych mohl trochu optimalizovat i v PHP... ale člověk tam instinktivně píše co nejsrozumitelněji... a navíc ani není jasné, která feature jazyka tam zdržuje kolik a tak...

kthx, neat: :D anyways:

Ad 1) No, v SQL taky clovek pise normalnizovane a pekne a srozumitelne a instinktivne. A pak potka vykonovou realitu. Nejak nevidim duvod, proc by to v php melo bejt stejny.

Ad 2) Neni jasne? Protoze...errr...protoze to neznas a nemeris?

A vytvarim 3): Z bodu 1) mi teda vyplyva, ze nejvetsi ficura prepisu do C je ta, ze v C clovek instinktivne nepise co nejsrozumitelneji, ale co nejvykonneji.

REDGUY: ... což jsem u svých projektů elegantně chtěl řešit použitím makro-wrapperů, které by pomohly obcházet případné dílčí nekompatibility knihoven či platforem ... :-) (což je nápad, který se výrazně osvědčil např. u javascriptové knihovny JQuery ...)

jinak máš pravdu částečně - norma POSIX se právě snažila striktně definovat i kompatibilitu hlavičkových souborů k běžným knihovním funkcím, a v řadě přídů se toto opravdu už 10 a více let nezměnilo.

REDGUY: já se ale nechtěl omezovat na datové struktury SQL - šlo mi vysloveně o to, že bych napsal jednořádkový SQL dotaz, který by mi pre-compiler rozexpandoval třeba na 10 řádků volání knihovních C funkcí... možná je to celé blbost, ale rozhodně mi místo toho nepodsouvej vlastní hloupé nápady, které nějak automaticky předpokládáš i u mě :-)

ALMAD: ... errr, protože v PHP omáčka okolo trvá 0.5 sekundy? přesto, že není jediný důvod, proč by měla?

třeba proto, že v PHP se na sloupce ve výsledku odkazuji pomocí $vysledek['klic'] - zatímco libmysqlclient mě trochu spartánštěji vede k použití číselných indexů do pole reprezentujícícho jeden řádek z výsledku dotazu? jasně, že bych mohl trochu optimalizovat i v PHP... ale člověk tam instinktivně píše co nejsrozumitelněji... a navíc ani není jasné, která feature jazyka tam zdržuje kolik a tak...

BTW můj typický jednoduchý dotaz do tabulky trvá 0.00 sekund(...)
to beru jako finální argument, proč chci bastlit webové aplikace v Céčku místo v PHP(....)

Cely svet je plny jednoduchych dotazu co trvaji 0.00 sekund (ano, nejspis proto ze se index vejde do pameti a na jednom nodu), takze chceme bastlit v Ccku, protoze...err...to dava smysl.


XCHAOS: Mel bych takovy dotaz...kdyz si delas tu predstavu...jakej ze tam byl vlastne engine?

Me ponekud desi ze tu hazes "nenavidim externi enginy, mam rozbitou tabulku a haze mi to chybu" hlasky a pri tom ani nenapises, co za engine v mysql si pouzil.

Jakoze vzhledem k tomu, ze mysql engines jsou od sebe tak daleko, ze jsou to de facto separatni databaze (maj jiny vlastnosti, jiny zpusoby optimalizace, jiny modely zamykani, ...), tak to je podobna kravina, jako kdyby na zaklade toho ze mu pro nejakej pripad maly appky zralo vic parsovani na frontendu nez pristup k datum a vubec neresil nejaky skalovani (tj. jak moc muze pridavat dalsi fe vs. db stroje) vyvozoval, ze ma cenu to psat v rychlejsim fe jazyce, co bude radove pomalejsi na vyvoj.

Oh wait.

XCHAOS: ale já právě počítal s tím, že by se v takovýchto tabulkách pak místo číselných primárních klíčů používaly přímo pointery - nejde jen o pouzivani pointeru. Jde o to, ze pokud mas primej pristup do pameti, muzes pouzivat mnohem sirsi skalu datovej struktur nez nabizi SQL a tudiz je pitomost se na nej omezovat.

XCHAOS: Výrazným rysem samotného jazyka C je zpětná kompatibilita - Hello, Captain Obvious. Coz je bohuzel tvrzeni v podstate o nicem. Jednak proto, ze podobne zpetne kompatibilnich je i spousta dalsich jazyku, druhak proto ze samotna kompatibilita jazyka je ti uplne na houby, kdyz se ti knihovny meni pod rukama a tu a tam se dokonce zmeni i format executable.

ale upřímně: nevím, jak to tam je se zpětnou kompatibilitou reálně - my vime 8))

Pokud vím, tak javové aplikace ani nebyly přenositelné mezi mobilními telefony a webovými browsery) - coz je podobne pitome tvrzeni, jak rikat ze Cckove programy nejsou prenositelne mezi Arduinem a Linuxem. Viz vyse, problem neni v jazyce, ale v knihovnach a v tom ma C problem jako vsichni ostatni.

REDGUY: ...ale já právě počítal s tím, že by se v takovýchto tabulkách pak místo číselných primárních klíčů používaly přímo pointery... přesto by ale kód vznikl kompilací "human readable" SQL dotazu. akorát by např. to id v takovéto tabulce pochopitelně byl vždy přímo pointer, a relace by byly přímo do paměti.

REDGUY: to je samozřejmě zajímavá teorie... teď teda nezbývá počkat, než mi nějaká SQL databáze ukáže různé DESCRIBE pro různé obsahy tabulek. zatím mě vždy přišlo, že na to má vliv jen struktura dotazu a struktura klíčů u tabulek.

DAVIDOWITCH: připouštím, že nemám představu, jak uvnitř vypadá databáze... ale na základě chyb, které mi hází MySQL, si postupně nějakou dělám :-)

TENCOKACISTROMY: kvůli té životnosti jsem se přeorientoval na Linux/POSIX - víceméně, rozkoukávám se v unixovém světě cca od roku 1994, a i když nějaké použitelné výsledky mám teprve tak asi tak maximáně posledních 10 let, tak to, co bych naprogramoval v roce 1994 např. v Bashi (nebo i v Céčku, možná v Perlu), to by mi běhalo (šlo přeložit) nejspíš i letos. Tedy důvodem proč jsem se přeorientoval, byla právě potřeba nadčasové platformy, která přežije i výměnou generací hardware (takových výměn hardware/OS jsem v té době měl za sebou už několik - a pochopitelně mi naštvalo, že cokoliv jsem do té doby naprogramoval, se vždy stalo bezpředmětné...)

Výrazným rysem samotného jazyka C je zpětná kompatibilita - specifikace C99 je podle mých zkušeností zpětně kompatibilní s C89, a to zase bylo víceméně kompatibilní s původním K&R C

Něco podobného slibovala Java - ale upřímně: nevím, jak to tam je se zpětnou kompatibilitou reálně. (Pokud vím, tak javové aplikace ani nebyly přenositelné mezi mobilními telefony a webovými browsery)

XCHAOS: A me jednou neco jinyho spadlo na segfault! Hruuuuza!
XCHAOS: Ano, resit zivotnost SW v desitkach let v prostredi/obdobi, kdy po deseti letech mas problem sehnat HW na kterym to muze bezet mi prijde absolutne mimo. Neco jinyho by bylo, kdyby si byl i vyrobce dotycnyho HW, tak by to davalo smysl.

XCHAOS: Nemam. Pokud mas data natolik jednoduchy ze je muzes mit ve vlastni pameti ve vlastnim procesu, nemas pouzivat SQL.
Pokud je nemas natolik jednoduchy, tak si ten pointer nevymyslis.
Mne to cim dal tim vic zni jako ze bud pouzivat MySQL na neco na co to je zbytecny, nebo nemas predstavu jak vypada uvnitr databaze (a tudiz si to stylem sobe vlastnim predstavujes jak hurvinek valku).

XCHAOS: fakt mě přijde, že toto jsou tak samozřejmé věci, že o nich prostě nemluvím. - me spis prijde ze o tom nemluvis proto, ze to je problem 8))

tam samozřejmě kapituluju - no slava.

ovšem o tomto typu optimalizace mi např. DESCRIBE u MySQL neříká nic - jak, nerika? Rika. Tedy, nevim jestli MySQL pri optimalizaci bere do uvahy velikosti a obsahy tabulek, ale pokud ano, tak vysledek DESCRIBE ti rika, jak bude dotaz vypadat pro AKTUALNI data. Neni duvod proc by ti rikal, jak by se dotaz provadel kdyby v tabulkach byly uplne jiny data.

XCHAOS: ale dostat rovnou pointery do paměti - podivej, pokud mas rovnou pointery do pameti, tak se fakt nemusis srat se SQL datovym modelem kde jsi omezenej na hejno tabulek. Kdyz to mas v pameti, tak proc delat nejakou bizarni relaci mezi tabulkama Users, Posts a UserPosts, kdyz muzu proste muzu mit objekt User kterej bude mit pole/list/whatever pointeru na objekty Posts. Proste pouzijes normalni datovy struktury urceny pro praci s datama v pameti.

no nic. čau.

REDGUY: tak z podstaty pre-kompilace tak nějak vyplývá, že v případě modifikace těch tabulek by bylo nutné aplikaci kompilovat znova. fakt mě přijde, že toto jsou tak samozřejmé věci, že o nich prostě nemluvím. (jeden z důvodů, proč chci optimalizovat je, abych mohl SVOJE vlastní aplikace provozovat i bez adminů - protože ti se historicky ukázali jako nejnákladnější a nejnepředvídatelnější položka vůbec...)

co se optimalizace query podle obsahu a nikoliv podle struktury týče - tam samozřejmě kapituluju. (ovšem o tomto typu optimalizace mi např. DESCRIBE u MySQL neříká nic...)

XCHAOS: Nevím, jak tě mohlo napadnout, že ten precompiler by neměl informace o tom, nad kterými sloupci má k dispozici indexy a nad kterými ne - to je přece základ. - coze? Ty v dobe kompilace presne vis, jake indexy bude mit ten program za pul roku k dispozici? Wow, magic. A i kdyby, znamena to, ze pri kazde zmene databaze (treba pridani indexu), ktera u normalniho SQL vubec nevadi, budes muset prekompilovat aplikaci? To zni skvele.

A hlavne, stale ignorujes (nebo proste nechapes) fakt, ze query optimizer bere do uvahy i _obsah_ databaze, ne jenom jeji strukturu. Opravdu jsi takovej vizionar, ze pul roku dopredu znas nejen strukturu, ale i obsah databaze?

DAVIDOWITCH:
DAVIDOWITCH: ... snad alespoň ty bys mohl mít pochopení pro to, že podstatou celé myšlenky bylo netlačit data přes socket, ale dostat rovnou pointery do paměti... tedy eliminovat z procesu tlačení dat přes socket.

protiargumentem bylo, že v éře CPU cache (to je věc, která se začala běžně používat až poté, co já si běžně přestal hrát se strojovým kódem - takže pro mě intuitivní dělení je pořád "paměť vs. disk" ačkoliv dnes je to častěji "cache vs. paměť vs. disk") , nota bene v éře swapování na disk :-) je mi stejně pointer do paměti platnej asi jako kreditní karta k účtu, na kterým vůbec nemusí být peníze. bohužel to asi protiargument bude, tak se soustředím nadále na to, čím tráví PHP tu půl sekundu času...

REDGUY: je asi jednodušší ponechat ti poslední slovo, než snažit ti podesáté něco vysvětlit.