Nevyhazujte vase penize z Window

4.7.2008 19:58 | Přečteno: 2080× | database

Tento nadherny reklamni slogan nemecke firmy UsedSoft a jejich soudni potycka z firmou Oracle si zaslouzi byt blogovany. Firma UsedSoft se zivi nakupem starych softwarovych licenci a jejich prodejem. V pripade 'Oracle' nyni dostali pres prsty. To je dobra zprava, zejmena pro OpenSource.

Jak znamo, firma Oracle neporodava software ale jako vetsina jinych vyrobcu prodava pouze pravo uzivat Oracle software. Navic nedovoluje firma Oracle pouzivat sve software bez udrzovatelskych poplatku a proto kdyz nekdo neprodlouzi podporu, tak mu Oracle nemilosrdne sdeli, at kouka vsechny kopie software znicit.

Pro kolegy, kteri se v DB oblasti tolik nevyznaji jen strucne - firme Oracle vdecime za ten nesmysl - relacni databaze - ktere nas dnes a denne provazeji a zdrzuji od prace. (jako posledni odstarsujici pripad viz diskuzi 'sql dotaz' na linuxsoft.cz.). Firma Oracle zvedla minuly tyden drsne ceny, protoze jeji sef Larry (ne Wall) Ellison potrebuje asi novou jachtu, Hasso Plattner ze SAPu ma toho casu pry rychlejsi) a jiste jsou panove z Oraclu radi, ze usedSoft jejich software skutecne nesmi dal prodavat. Tu fintu s tou provazanosti licenci a podpory si od Oraclu omrklo stale vice firem a tak se z jednoho CD stava 'sluzba'na pocitacich zakazniku. Je to nepekna praxe, ktera odepira svobodu rikaji ti jedni (Havel, zeleni, Bob Dylan, Hynek Hanke, ...), - vse v souladu z trznim hospodarstvim tvrdi ti druzi (napr. otec reditele jednoho soukromeho gymnazia).

At uz jsou nazory jakekoliv, oteviral by se zde prostor pro svobodne software. Oracle a DB2 jsou produkty, ktere potrebuje tak akorat 5% vsech zakazniku, zbytek by vysatacil z opensource produkty. Proc je i pres ocividnou nesvobodu a dojeni zakazniku pozice Oraclu presto zatim neotresitelna. Odpoved jsem nasel zde v diskuzi.

Je to dano skladbou a urovni jak beznych, tak odpovednych IT pracovniku ve firmach. Jiste rada cetla ten blogpost toho mladeho PHP-kolegy, ktery hleda smysl zivota. V diskuzi jsme se dovedeli, jak Anicka dava zaludne priklady zajemcum o misto v SUSE. Je mozno se divit, ze se nenajde zadny zodpovedny pracovnik, ktery by zduvodnil Postgresql - kdyz odrostle deti vedou prijimaci rozhovory s detmi?

Kdybych umel zadat anketu, tak bych polozil jednu jedinou otazku - take povazujete relacni databaze za nesmysl? A vysledek by byl jednoznacny a poradna facka pro cely IT prumysl - max. 5% by odpovedelo kladne. I kdyz je treba uznat, ze takove ankety jsou mnohdy sporne - napr. jak 70% obyvatel CR si mysli, ze 'on' je tim spravnym.

       

Komentáře

[Ladicek]

Je to možné – dvakrát v jednom zápisku?

S tím Oraclem to je pěkná finta, k tomu se snad nesníží ani malý měkký (nebo jo?).

[Luboš Doležel (Doli)]

Teď jsem někde četl, že budou v USA prodávat Office s licencí na jeden rok

[Stevko]

Hm, niekto pozná Little Brother (pätička). Ja som nemal nervy dočítať to (niekde za polovicou som asi bol).

[Luboš Doležel (Doli)]

Tak daleko ani nejsem, nějak si na to neumím najít čas, takže to jde pomalu.

[Filip Jirsák]

Není mi moc jasné, proč z toho dělají takovou novinku. Microsoft licenci Sofwate Assurance (platí se za pronájem softwaru a během předplatného období můžete používat vždy nejaktuálnější dostupnou verzi programu) nabízí už dost dlouho, jednu dobu to dost tlačili místo různých Selectů apod.

[Käyttäjä 11133]

kdyz odrostle deti vedou prijimaci rozhovory s detmi?

Ty jsi mi ale pořádný kus sebestředného idiota.

[Martin Böhm]

Nebuď tak absolutní... tahle věta se mi líbila a je (mnohdy) pravdivá. Odrostlé děti vedou přijímací rozhovory s dětmi.

Než nadávat jako dlaždič, tak to vezmi s nadhledem... někdo je prostě odrostlé dítě, a někdo je senila, co neudrží krok s dobou, a tak musí nadávat, jaké to bylo zamlada a jak by všechny ty internety zakázal. :o)

[anicka]

Co si lhat do kapsy, kdyz jsem nastupovala do firmy, byl tam prumerny vek pod 25 a mne dvacet... a dneska je oboje jen o par let vic. Mezi "mladymi" a "odrostlymi detmi" neni zas takovy rozdil, zalezi jen na uhlu pohledu a veku toho, kdo se diva A Linux je prece pro studenty, ne?

Dokud ty odrostle deti dokazou na pohovoru odfiltrovat vsechny lidi, kteri veri na nutnost pouzivat na kazdou skopicinu relacni databaze (hint: ti, co veri na LDAP jsou jeste horsi), je myslim vse zcela v poradku

On je ten komentar IMHO hodne mimo uplne z jineho duvodu. Ve firmach, kde se veri na databaze, obvykle nedelavaji pohovory deti, to plati obcas jen v te nasi a podobnych. A deti obvykle mivaji korporatnimi predsudky nazatizeny pohled na vec...

"databaze" - "HR specialista" - "best practices" - "enterprise" ... nekoreluje nam to nejak? Ja bych databazniky hnala svinskym krokem, ale predstavte si na mem miste (nebo na miste nejakeho mladeho kolegy, ja uz to zas dneska nastesti nedelam) na pohovoru manazera v kravate

Takze ta odpoved nalezena v diskusi je IMHO zcela mylna. Problem jsou spis zkuseni manazersti veterani zatizeni furou predsudku, nez my, co jeste umime myslet vlastni hlavou Skoro se citim urazena, ze jsem podezirana z opaku :-P

[thingie]

Ono jak se lidi dostanou do fáze kdy se nemaj za děti, tak už jsou stejně leda na odstřel.

[springer]

v tom mame my muzi vyhodu, my zustavame stale detmi ...

[springer]

takze trochu po lopate. Zadavate v ramci pohovoru nejakou praktickou ulohu a kontrolujete, jak ji uchazec zvlada. Kdyz odhledneme od tremy a jinych psychickych faktoru, ktere uz samy mohou spravny dojem totalne zkreslit, tak to nejotresnejsi je, ze se tim prikladem pokryje max. 10% vsech cinnosti, ktere budou v prubehu pracovni cinosti pro firmu hrat roli. A tim testem se zjisti, ze uchazec tech 10% splni na +/- 50%. Efektivitu firmy to vubec neovlivni. Proto se to take v rozumnych firmach nedela.

Muj dojem je, ze rajtujete v pohovoru na nepodstatnych kravinach a vyznamne skutecnosti utikaji nebo o nich eventuelne ani nevite. Jsem si jist, ze na rozdil od nekterych ostatnich jiz davno vite, ze to neni mineno osobne, ze Anicka je pro me synonymem mladeho angazovaneho cloveka, ktery vhozen do vody nyni musi plavat.

Ale jak pisete, predstava, ze ve firme je prumer pod 25 let - reknete uprimne, neni to silene.

[Luboš Doležel (Doli)]

Hrubý filtr pořád lepší než žádný filtr. Zajímalo by mě, jak by jste se vy snažil zajistit nějakou kontrolu kvality - třeba se Anička poučí.

[thingie]

Šílená je třeba představa, že někde o něčem rozhodují lidé co jim bylo víc jak pětatřicet*. A tak.

*Jako třeba v téhle zemi. A spoustě jiných. Vypadá to podle toho.

[laco]

Většinou to tak bývá, že na vedoucích postech jsou ti starší.

[thingie]

Po většinu historie lidstva tomu bylo tak, že většina lidí takového věku zastávala jediný post, totiž že byla už mrtvá. A ono to tehdá mělo něco do sebe.

[xsubway]

Bylo by zajímavé porovnat tento názor s tvým "postojem" až ti bude více než 34 :-P

[JS]

Delam ve programatora v (zahranicni) SW firme, kde je vekovy prumer programatoru pres 50 let. A je to uchvatne. Vetsina tech lidi vi naprosto presne, co dela. Nepodlehaji zadnym modnim vlnam. Jasne, mozna jsou trochu pomalejsi a nepouzivaji nejmodernejsi postupy, ale pokud mate nejaky problem z jejich oblasti, diagnostikuji vam ho behem nekolika minut. Kdyz to srovnam sam se sebou (jsem mladik), tak mozna obcas mam nejaky inovativni napad, ale spousta veci delam nesikovne. Od starsich lidi se clovek muze hodne naucit; kdo to nezazil, tak nevi. A to nemluvim o tech historkach..

Podle me je dulezita vyvazenost. Kdybych nekdy zakladal vlastni podnik, urcite bych chtel mit aspon jednoho starsiho zkuseneho zamestnance, aby se vytvorila protivaha.

[Miloslav Ponkrác]

Naprosto souhlasím!!! Podepisuji! Dělat s kolektivem, kde jsou pouze mladí nezkušení lidé, samozřejmě dynamičtí, je dost často hrůza. A musím říct, že často při spolupráci s jedním dvěma lidmi nad takových 30-35 let se často udělá práce kvalitněji, rychleji a efektivněji, než s támem pěti mladých dynamických osobností.

To co píšu platí pro programování - mě už přestává bavit přesvědčovat dvacetileté o užitečnosti dobrého návrhu architektury programu, či databáze. Nepřesvědčím - oni chápou jen sednou a začít něco dělat. Že pak výsledek nestojí za to, zvláště pokud se nedělá malý projekt jim neva.

Ale abych neházel do jednoho pytle - je spousta mladých lidí, kteří ví, kde jsou jejich meze, a mají ctižádost to dotáhnout daleko i jinak, než dynamickými sebevědomými frázemi. S těmi se spolupracuje báječně.

[thingie]

Jo, určitě lidé postupně zvládnou věci co umí lépe. Ale člověk co se naučil programovat před třiceti lety bude lépe zvládat jenom to programování před třiceti lety. Ono to sice v zásadě tolik nevadí, protože to naše slavné programování (minimálně v podobě kterou provozuje většina světa) od té doby prodělalo tak malý pokrok, až to bolí, ale dobře to nejni.

[Kyosuke]

Jestli se naučil programování před třiceti lety v AI labu MIT, tak umí věci, které někteří neumějí dodnes.

[thingie]

„(minimálně v podobě kterou provozuje většina světa)“

Proč to tam asi bylo. Jistěže v okrajových případech se přišlo na spoustu zajímavých věcí, jenže ty se do „mainstreamu“ dostávají -- v kontrastu s všemožnou propagandou označující IT za rychle se vyvíjející a měnící obor -- katastrofálně pomalu. Takže se třeba ptát, proč tomu tak je. Já mam tip, kterej jsem tu přednesl.

[MJ]

Šílené je především, že o věcech rozhodují lidé, kteří neumí uvažovat. To s věkem jaksi nesouvisí – z mladého blbce se vám nejspíš stane jen a pouze starý blbec.

[Filip Jirsák]

Zadavate v ramci pohovoru nejakou praktickou ulohu a kontrolujete, jak ji uchazec zvlada. Kdyz odhledneme od tremy a jinych psychickych faktoru, ktere uz samy mohou spravny dojem totalne zkreslit, tak to nejotresnejsi je, ze se tim prikladem pokryje max. 10% vsech cinnosti, ktere budou v prubehu pracovni cinosti pro firmu hrat roli.

Ono nejde o to, jak dotyčný zvládne tu konkrétní činnost, ale především o to, jak se k celému problému postaví. Jestli si třeba vůbec pozorně vyslechne/přečte zadání, jestli se nebojí zeptat atd.

[MJ]

Efektivitu firmy to samozřejmě ovlivní, a to značně. Potřebujete totiž zjistit zejména to, zda je uchazeč o věcech schopen přemýšlet, a na to je nejlepší právě jednoduchá praktická úloha, byť by třeba ani nesouvisela s jeho budoucí pracovní náplní. Tak odfiltrujete lidi, kteří se jenom naučili pytel módních frází, od těch, kteří něco doopravdy dovedou.

[springer]

nejdriv jednu zajimavou zkusenost z konce 90 let. Ve firme, v ktere jem tenkrat pracoval , prijali kolegu, vystudoval kybernetiku. Programovat umel (tenkrat to bylo ve Fortranu na VAXech) ale mel jeden problem - neuveritelne se potil a bylo to dost citit. Produktivita v te kancelari klesla na bod mrazu ale Anicka by ho prijala, protoze stringy umel otacet ve spanku.

Nemluve o tech potizistech, kteri vice zdrzuji nez udelaji. To co zkousi Anicka neni nic jineho, nez zjistit, jestli nekdo takovy nezfalsoval papiry. Jestlize ma nekdo vysokou skolu, tak ho uz pak nepotrebuji zkouset a nebo jsou ty diplomy na hovno.

Ted k tomu programovani - v kazde knizce o sw-inzenyrstvi se docteme, ze programator a programy ovlivni hospodarsky vysledek firmy z 10%. Ve firme jsou mimo programatoru take ucetni a sekretarky reditelu a vedoucich oddeleni a ty jsou nemocne a nevrazive atd... atd. Kdyz se udela pitome rozhodnuti ve vedeni a pri planovani projektu tak vas pak nezachrani ani kdyby se vsichni programatori ve firme jmenovali treba Ponkrac. A jestli v techto 10% nekdo otaci lepe stringy se projevi v desetinach promile, jestli je to vubec zjistitelne.

Mnohem podstatnejsi jsou otazky infrastuktury. My predloni hledali propgramatora a protoze je vsechno unix, tak jsme chteli aby umel s vi-editorem. Protoze jsme nikoho takoveho nesehnali, tak jsme vzali jednoho, a ten pres Sambu editoval s notepadem++ (ten totiz umel). Pote, co si nekolikrat smazal naeditovany program jsme ho museli vyhodit. Stringy otacel take dobre, ale my jsme podcenili tu infrastukturu.

[koty]

Hele, v kolika solidních firmách už jsi dělal pohovory na programátorské pozice ? Praktické testíky člověk schytá v naprosté většině firem, jenom většinou až v tom závěrečném kolečku po x kolech filtrace přes slečny z HR. A ani v SUSE nejsou alfou a omegou při rozhodování. Ano, je to svým způsobem prověrka, zda uchazeč prostě jenom nekecal v živočichopisu, jaký je borec, dá se při tom zjistit i to, jak reaguje na stres a jak je schopný si obhájit svůj názor před budoucím šéfem. Navíc je to taky jedna z mála příležitostí, kdy se budoucí šéf může s možným budoucím uchazečem setkat tváří v tvář a prověřit si, že si prostě sednou. Při běžném pohovoru to funguje tak nějak míň.

Jinak diplom není záruka vůbec ničeho. Jeden vlastním taky a kdybych měla projít přes Aničku, asi mě zatluče do země . Každý se prostě i přes podobné vzdělání orientujeme trošku jinak jeden chrochtá blahem, když může céčkovat, druhý to nějak zbastlí. Takže pro zoufalce, co teď šrotí jednostranně jeden druh úloh, Anička má nepřeberné množství vykutálených úloh a nejspíš je jako všichni rozhazuje podle dojmu, co který uchazeč alespoň trošku zvládne.

Co se týká smrdutého kolegy, myslím, že by dost záleželo, jak moc smrdí. Co vím, i Anička má nos. Na druhou stranu SUSE je celkem plné jedinců produkujících různé děsné pachy i bez pocení. Na pocení máme firemní sprchy a nefiremní deodoranty .

Co se týká těch 10%, podobná situace je ve všech oborech. Lidi, co produkují výrobky, se prostě můžou snažit jak chtěj, ale pokud je zbytek firmy děs a hrůza, stejně se neuživí. Každý článek je prostě důležitý. Doufám, že v těch všch knížkách, co čteš, je taky uvedeno, že je dost velký rozdíl, když přijmeš jednoho flákače do malé firmičky o třech programátorech nebo takové hezké korporace, kde jich je pár desítek v jedné pobočce. První totiž může jeden flákač programátor sejmout stejně dobře jako mizerný managor.

Tvoje otázka infrastruktury je spíš smutné potvrzení toho, že na základních požadavcích na pracovníky je prostě třeba trvat a jsou hranice, za které se už necouvá. Nehledě na to, že kdybys toho človíčka prohnal testíkem, nejspíš bys tušil, že se to prostě nenaučí.

[JS]

Takže pro zoufalce, co teď šrotí jednostranně jeden druh úloh, Anička má nepřeberné množství vykutálených úloh a nejspíš je jako všichni rozhazuje podle dojmu, co který uchazeč alespoň trošku zvládne.

Hmm, to SuSE zni cim dal tim vic lakave. Premyslim, ze bych si z toho vazne udelal sport - chodit na pohovory jenom kvuli tem uloham (nebo debilnim otazkam na "laternalni uvazovani"), co tam clovek dostane. Kdyz slysim kolem sebe ty historky - treba v jedne bance nechali pry toho cloveka resit diferencialni rovnici, do toho bych sel hned, i kdyz vubec nevim, ktera bije. Pokud clovek zrovna nehleda praci, musi to byt uzasna zabava. No, treba nekdo zalozi takovy klub, kde si budou ucastnici navzajem vymenovat prakticke zkusenosti, ktera firma na pohovoru zadava ulohy a ktera ne.

[anicka]

debilnim otazkam na "laternalni uvazovani"

To je co?

chodit na pohovory jenom kvuli tem uloham

A to by Vás bavilo? Ježkovy zraky - vždyť jsou úplně hloupé a jednoduché Zkuste spíš příště naši online soutěž, tam bývají k vidění ty nejlepší úlohy, co v SUSE umíme (ale u pohovoru by je mohl dostat leda tak MJ, a tomu bych ve vstupu do SUSE bránila vlastním tělem).

[JS]

debilnim otazkam na "laternalni uvazovani"

To je co?

To jsou takove ty hypoteticke problemy, co jinak nikdo v praxi neresi. Napriklad, jednou jsem slysel, ze nekdo na pohovoru dostal otazku: "Mame horu v Indii a chceme ji mit ve Francii. Jak?" Sice nemuzu vedet, jak bych pri tom pohovoru dopadl, ale moje odpoved "Proc?" se nesetkala s pochopenim kolegu; ja si ovsem myslim, ze pokud mam jako inzenyr neco udelat, musim pro spravne reseni vedet, proc to vlastne chci udelat. Protoze co my vime? Treba jim nejde ani o tu horu, ale potrebuji jenom nejaky vzacny material z ktereho sestava. Nebo je na jejim vrcholu nejake svate misto. A tak podobne. No kazdopadne, i takovehle divne otazky kladou pri nekterych pohovorech.

chodit na pohovory jenom kvuli tem uloham

A to by Vás bavilo? Ježkovy zraky - vždyť jsou úplně hloupé a jednoduché Zkuste spíš příště naši online soutěž, tam bývají k vidění ty nejlepší úlohy, co v SUSE umíme (ale u pohovoru by je mohl dostat leda tak MJ, a tomu bych ve vstupu do SUSE bránila vlastním tělem).

Nevim, jestli by me to bavilo. Akorat me prepadla takova ta dobrodruzne-romanticka nalada a prislo mi to jako zabavna myslenka. Jestli jsou jednoduche, tak byste se asi nedostali moc vysoko na ten hypoteticky seznam cilu. Ale nektere firmy davaji docela zajimave. Jednou jsem v Technicke knihovne cekal na knizku, a protoze jsem se nudil, zacal listovat nejakymi Linuxovymi casopisy. A co cert nechtel, dvoustrankova reklama na Google Labs spojena s problemem (byl to takovy automat na tycinky od cokolady). Tak jsem si ji okopiroval. Docela pekne na te uloze bylo, ze se asi neda vyresit mozkem (tedy, mluvim pouze za ten svuj ), ale musi se nechat spocitat na pocitaci.

Online soutez mozna vyzkousim, pokud mi poslete odkaz, diky.

A ze jsem tak smely, proc byste branila MJovi vstupu do SuSE? (I kdyz, jak ho znam, tak byste asi nemela sanci.)

[Käyttäjä 11133]

A ze jsem tak smely, proc byste branila MJovi vstupu do SuSE? (I kdyz, jak ho znam, tak byste asi nemela sanci.)

Asi proto, že není zrovna vhodné s jedním člověkem pracovat a zároveň žít... To je jako když spolu začnou na základce/střední chodit dva spolužáci, většinou to nedopadne dobře. :D

[Kyosuke]

<rejp>spíš by bylo horší s jedním člověkem pracovat, žít s ním a ještě si od něj nechat dávat známky, než s nám "jen" žít a nechat si od něj dávat známky. <rejp>

[springer]

no kdyz uz jsme se dostali tak daleko, tak nemohu nez konstatovat, ze Anicka ma jednu vyhodu. Kdyz ji MJ da blbou znamku, tak ho da pred soud jako ty devcata Kulinskeho ...

[anicka]

Kdyz ji MJ da blbou znamku, tak ho da pred soud jako ty devcata Kulinskeho

Jo... i kdyby to nebylo absurdni z mnoha jinych duvodu, predstav si ten soud:

Evidentne davno plnoleta zenska znama v ceske BDSM komunite zhruba tak jako v te linuxove (zejmena pachanim vselikych prostopasnosti), zaluje nekoho, s kym nekolik let bydli, za zneuzivani. No jestli by ten soudce nepuknul smichem

[JS]

BDSM? Tak to by se vam libil muj smrtelne nebezpecny trik se salou, nebo zahadny matematicky trik s provazem.

[springer]

ale mozny to docela je, ze te takhle zatizena. U linuxacek je to totiz dost obvykle. Bohuzel to uz nemohu najit ale asi tak v roce 2003 byla nejaka open source evropska konference v Brusselu nebo Amsterodamu a za nemeckou stranu o tom referovala na netu nejaka linux-adminka z Karlsruhe. Byl tam odkaz na jeji stranku, a jednu z jejich erotickych povidek co tam byly (byly to jeji fantazie) si dodnes pamatuji. Nejakej jeji vzdaleny pribuzny ji na rodine oslave svazal v temny mistnosti, daval ji ty koliky na pradlo na ty ruzny mista a tyral ji tim, ze ji ne a ne znasilnit.

Kdyz si to tak promitnu v hlave, tak se SUSe koncim a jdu do Slackwaru ...

[Kyosuke]

Tak to je prozatím asi nejpádnější důvod ke změně distribuce, na který jsem zatím narazil...

[anicka]

Kdyz si to tak promitnu v hlave, tak se SUSe koncim a jdu do Slackwaru ...

Mne pomerne nedavno bez vysvetleni zahadne zmizel obusek, co jsem mivala v SUSU v supliku, takze jsem ted celkem neskodna

[JS]

Programovani bude mit hodne spolecneho se S/M. Polovinu casu (no, mozna tak 10% ) je clovek slasti bez sebe, ze pocitac dela to, co se po nem chce (ostatne podeziram programatory, ze to je duvod, proc tu praci delaji - mohou mit vlastni svet, nad kterym maji uplnou kontrolu). A druhou polovinu zase stena zoufalstvim, kde jen udelal chybu, ze to nechodi; a to vse aby si pak s ulevou vydechl, az ji objevi.

[anicka]

Online soutez mozna vyzkousim, pokud mi poslete odkaz, diky.

Online soutez bude zase az tak nekdy v listopadu, ale muzete si aspon zkusit nejake ulohy z tech predchozich. Momentalne maji koukam labaci nejaky rozbity web, ale casem snad zas budou videt tady a tady. (Dam jim o tom vedet.)

A ze jsem tak smely, proc byste branila MJovi vstupu do SuSE? (I kdyz, jak ho znam, tak byste asi nemela sanci.)

Uz jsem si vyzkousela, ze mit vztah s nekym ze SUSE nemusi byt az tak uplne chytre A pokud jde o sance, MJ je sice tvrdohlavy, ale ja taky, takze tezko rict

[MJ]

MJ je především tak tvrdohlavý, že by stálo hodně přemlouvání, aby se v tomto oboru vůbec někde zaměstnat nechal

[Käyttäjä 11133]

[xkucf03]

Chtít zrovna po programátorovi aby uměl vi je dost ptákovina. Neřeknu, kdyby to byl admin, který má spravovat nějaké prastaré Solarisy, kde nic jiného není.

[MJ]

Chtít ne, ale podle toho, jakým způsobem (a zda) někdo používá vi, poznáte ledacos

[xkucf03]

A když ho používá jen v případech, že nic jiného není k dispozici, tak to znamená co?

[Käyttäjä 11133]

Že neobjevil jeho krásu?

[xkucf03]

Moje averze vznikla při používání toho starého vi na Solarisu. Uznávám, že vytuněný vim z moderních linuxových distribucí je oproti němu o něco přívětivější a použitelnější, ale stejně radši používám jiné editory.

[MJ]

Nemluve o tech potizistech, kteri vice zdrzuji nez udelaji. To co zkousi Anicka neni nic jineho, nez zjistit, jestli nekdo takovy nezfalsoval papiry. Jestlize ma nekdo vysokou skolu, tak ho uz pak nepotrebuji zkouset a nebo jsou ty diplomy na hovno.

On není diplom jako diplom. Upřímně řečeno, na úplně jiné otázky se budu ptát někoho, kdo má diplom třeba z Matfyzu nebo z MIT, než jiného, který si diplom vysloužil na informatice na VŠE.

[anicka]

Ted k tomu programovani - v kazde knizce o sw-inzenyrstvi se docteme, ze programator a programy ovlivni hospodarsky vysledek firmy z 10%.

Doufám, že si tu knížku jednou nepřečte nějaký náš chytrý šéf. Protože vyhodit českou a německou pobočku a najmout stejný počet programátorů v Číně by jistě znamenalo ušetřit neskutečné množství peněz na mzdách... co na tom, že už by pak nikdy nevyšla nová verze naší distribuce a firmu už nic nezachránilo před definitivním pádem do zapomnění

[xkucf03]

co na tom, že už by pak nikdy nevyšla nová verze naší distribuce

Zrovna linuxová distribuce je hodně universální a světová záležitost. Číňani by si s ní mohli poradit velmi dobře. Jsou ale jiné oblasti SW, které se nevyplácí outsourcovat.

[Filip Jirsák]

Jde o to, jací Číňani. Určitě jsou Číňani, kteří by se toho zhostili dobře, ale ti by asi nebyli o moc levnější, než Evropani. A ti opravdu levní Číňani by se toho nejspíš zhostili podobně, jako když někdo (tenkrát to byl myslím Ind) programoval cyklus začínající od 1:

for (int i = 0; i < count; i++) {
  if (i == 0) {
    continue;
  }
  …
}

[xkucf03]

njn, jsou to opice

(ale Číňani jsou větší machři)

[Ladicek]

To se jasně ukazuje latentní zvrhlost jazyků založených na Céčku, kde je všechno indexováno od nuly. To by se nám, Pascalistům, prostě nemohlo stát

[anicka]

Zrovna linuxová distribuce je hodně universální a světová záležitost. Číňani by si s ní mohli poradit velmi dobře.

No uz je vidim, jak si poradi s takovym yastem a jeho uchylnycm ycp...

Ti, co by se to byli schopni za nejaky rok dva naucit by opravdu nebyli levnejsi nez my

[anicka]

Zadavate v ramci pohovoru nejakou praktickou ulohu a kontrolujete, jak ji uchazec zvlada.

Jo, jasne. Jenze ta uloha byvala typu "otocte string na miste v libovolnem programovacim jazyce," a to jen a pouze tehdy, kdyz dotycny kandidat tvrdil, ze umi programovat. Klidne bych uznala i jednoradkovy perlovy program pouzivajici reverse, kdyby na to doslo, ale nikdy jsem takovou odpoved nedostala. Dokonce bych uznala i odpoved v jazyce, ktery si autor prave vymyslel, kdyby me presvedcil, ze to ma hlavu a patu. Samozrejme ma google a manpages a kdyz si rekne o nejaky cas, dostane ho. A tak podobne - vzdycky vskutku trivialni otazka z oblasti, o ktere predtim uchazec tvrdil, ze se v ni perfektne vyzna. Pokud nevyzna, lhal a nechci ho. Pokud to jine firmy nedelaji, je to jejich problem a nase stesti a konkurencni vyhoda. Protoze clovek, ktery neco neumi, se to nauci. Clovek, ktery lze uz na pohovoru, je i zadarmo drahy a nadela vic skody nez uzitku.

Ja jsem se pred svym prvnim pohovorem zacetla do Joela, ktery podle vseho vi co dela, a presto nedelam ani z poloviny tak silene veci jako on. Jen se snazim zjistit, jestli uchazec lze nebo ne, to je vsechno - specialne se nikdy neptam na veci z oblasti, ktere by sice IMHO mel znat, ale nesnazi se mi to namluvit.

Urcite jsou veci, ktere lidem muzou dat jedine dlouha leta zkusenosti (jako v tom vtipu s anglickym travnikem), ale bez tech se holt zatim musim zkusit nejak obejit a nahradit je zdravym rozumem. Jak je videt, spokojeny fungujici kolektiv, delajici kvalitni produkty, se da poridit i coby tlupa deti

Muj dojem je, ze rajtujete v pohovoru na nepodstatnych kravinach a vyznamne skutecnosti utikaji nebo o nich eventuelne ani nevite.

Na jednu stranu, nemyslim ze bychom se venovali nepodstatnym kravinam, na druhou, rada se necham poucit - jake vyznamne skutecnosti nam utikaji? Jestli to budu jednou delat znova, rada se naucim to delat lip

[xkucf03]

Clovek, ktery lze uz na pohovoru, je i zadarmo drahy...

Přikrášlovat vlastní dovednosti při pohovorech je běžná praxe. S tím bych se spíš smířil a ověřoval skutečné schopnosti, než formality, jestli uchazeč lhal hodně, málo, nebo vůbec.

Jeden z pohovorů, kterými jsem prošel, byl vedený velmi profesionálně a byl z toho příjemný zážitek, žádný stres. Ale nedovedu si představit, že by ta paní zvládala jak HR, tak programování* (to by pak nedělala pořádně ani jedno).

*) od toho tam byli jiní.

[anicka]

Přikrášlovat vlastní dovednosti při pohovorech je běžná praxe. S tím bych se spíš smířil a ověřoval skutečné schopnosti, než formality, jestli uchazeč lhal hodně, málo, nebo vůbec.

Vidis. A mne prijde, ze ten rozdil mezi "uz jsem to nekdy videl, ale moc si to nepamatuju" a "jsem v tom vazne dobry" muze byt rozdil mezi tim, jestli ho chci nebo ne. A pokud nekdo nedokaze pochopit, ze kdyz se mu na zacatku predstavis jako programator, fakt na Tebe nema zkouset finty na damy z HR, jeho smula Prikraslovat a lhat jak kdyz tiskne je kazdopadne velky rozdil, ktery zohlednuju

Jeden z pohovorů, kterými jsem prošel, byl vedený velmi profesionálně a byl z toho příjemný zážitek, žádný stres. Ale nedovedu si představit, že by ta paní zvládala jak HR, tak programování* (to by pak nedělala pořádně ani jedno).

Kdybychom meli nejakou pani z HR, tak mozna nikdy nezamestnavame nekoho tak dobreho, jako je treba Blubear, jenom proto, ze by se pred ni klidne priznal ke svym depresim... diky, mne (a snad i ostatni u nas) zajima spis to programovani

Ostatne soudim, ze pres pani z HR bych nikdy na zadnem pohovoru neprosla

[xkucf03]

Ostatne soudim, ze pres pani z HR bych nikdy na zadnem pohovoru neprosla.

Tak to budeš mít v životě asi těžké , protože normální pohovory se dělají vícekolové a na prokazování technických schopností dojde až v posledních kolech.

[Kyosuke]

Ty pohovory bych označil za "běžné", ale nejsem si jist tím slovem "normální", to už je subjektivní popis, se kterým nemusejí všichni souhlasit.

[springer]

...Tak to budeš mít v životě asi těžké ...

zeny maji tu vyhodu, ze si vezmou minisukni, odvaznejsi halenku a kdyz je alespon v jednom kole u toho chlap , tak maj vyhrano ...

[MJ]

… pokud ten chlap není čistokrevný matfyzák

[Martin Böhm]

ooh, kde si můžu nechat udělat test? :o)

[xkucf03]

Copak jsou všichni z MFF jako BLEK? Spíš bych řekl: pokud ta ženská není průměrně hezká matfyzačka

[koty]

tak takhle to vážně nefunguje. První kolo jde vždycky přes HR, kde je 99% dam. A ty by polonahou slečnu s úsměvem nejspíš vyprovodily, i kdyby programovala jako bůh. Navíc mám ověřeno, že na většinu matfyzáků to zabírá, až když je na to člověk vysloveně upozorní. Nehledě na to, že musím konstatovat, že třeba já bych už odvážnou minisukni a halenku dostala spíš hodně mínusové body :-P.

[springer]

no, i kdyz to ted vyzni trapne, ale ja jsem si prohledl tu fotku toho prekladatelskeho tymu a kdyz odhlednu od tech panu (ten co sedi vedle vas , to je teda sila) tak i mezi temi divkami vypadate s odstupen nejlepe (samozrejme muj nazor). Pro posouzeni te minisukne je toho videt bohuzel malo, zrovna tak s tou halenkou. Ale vseobecne zase typicka zenska - male sebevedomi.

[Kyosuke]

Překladatelský tým? Jaký? Kde?

[anicka]

Ale vseobecne zase typicka zenska - male sebevedomi.

Spis zdravy rozum - my, co vypadame trochu jak otesanci, opravdu nemuzeme chodit v minisuknich. Coz samozrejme neznamena, ze nemuzeme chodit tak, aby nam to sluselo - a vime o tom. (Klara to narozdil ode me i dela. Mne prijde skoda casu nosit neco jineho nez nahodne platene kalhoty a susi tricko, co rano prvni vypadne ze skrine )

Nizke sebevedomi? Myslim, ze jeji nekdejsi podrizeni by na to meli jiny nazor A neni divu - nekdo, kdo dlouha leta delal telefonickou podporu, nemuze mit nizke sebevedomi, to by se zblaznil. Jo, mezi lidmi, co veri na genderove stereotypy, a temi, co vsude nasazuji ty relacni databaze, neni zas tak hluboka propast, abychom se vratili k puvodnimu tematu

[anicka]

Tak to budeš mít v životě asi těžké

Možná, možná ne - existují strategie, jak se tomu vyhýbat. Pokud jde o budoucnost, záleží na tom, jestli se v příštích letech bude víc projevovat mé introvertní já počítačového maniaka nebo extrovertní já normální ženské. Pokud to první, budu mít při troše štěstí mimo milionu nezajímavých susích patchů na svědomí taky nějaký pořádný projekt, který komusi vnukne touhu mě zaměstnat nezávisle na osobnosti. Pokud to druhé, budu nejspíš v případě potřeby hledat práci přesně týden aniž bych musela napsat i jen životopis přesně tak, jako to bylo posledně, protože budu v každodenním kontaktu s někým "kdo zná někoho, kdo zrovna někoho jako já zoufale shání."

Navíc, každá práce není v odporné korporaci s fůrou HR odborníků, ani ne přes agenturu... a jestli jednou opustím SUSE, věř tomu, že se budu vyhýbat jak čert kříži čemukoliv, co má víc než sto zaměstnanců nebo vedení v USA

[JS]

Ja delam v korporaci, co ma nekolikanasobne vic nez 100 zamestnancu a sefy v USA, a neni to tak strasne. Hodne zalezi na lokalnich sefech, s temi uplne nahore normalni smrtelnik neprijde do styku, takze.. Je to sice moje prvni prace, takze je tezke porovnavat, ale ted kolem sebe mam fajn lidi, a nemenil bych. Protoze jsem diky sve povaze nemel, kdo by me doporucil, schvalne jsem si vybiral praci ve vetsi korporaci, protoze u tech ceskych mensich podniku podle me jeden nevi - muze to dopadnout hodne dobre, ale take hodne spatne.

Dokonce jsem se diky tomu podival i do USA, coz je legracni, kdyz uvazime, ze z mych kolegu v Americe mohou podle internich pravidel cestovat jenom manazeri.. Takze, i kdyz jsou pro nas Rimany, jsou na tom vlastne hur.

[anicka]

Hodne zalezi na lokalnich sefech, s temi uplne nahore normalni smrtelnik neprijde do styku, takze..

Tohle funguje bez problémů, o tom žádná. Ale to nic nemění na tom, že shora padajícími stupidními rozhodnutími odtrženými od reality pobočky je bohužel nutné se řídit, ačkoliv jí to jedině ublíží a bude to desetkrát dražší.

Kdybych mohla vyprávět konkrétní historky, věřím, že by se osazenstvo abíčka umlátilo smíchy, ale smůla

[Kyosuke]

Já bych spíš nad některými hořce zaplakal...

[JS]

Kdybych mohla vyprávět konkrétní historky, věřím, že by se osazenstvo abíčka umlátilo smíchy, ale smůla

Ja si to castecne dovedu predstavit. Clovek si to ale nesmi brat osobne. Ja obecne neverim na efektivitu jakehokoli hierarchickeho rozhodovani (pokud tedy toho borce nahore v te hierarchii neuznavaji jako odbornou autoritu ti pod nim), ale to je na delsi (a politickou) diskusi.

[koty]

No, nechci ti brát iluze, ale i SUSE má HR. Naštěstí ale s velmi omezenou funkcí a CV filtrovat nesmí.

Že si uchazeč přibarví živočichopis, to se tak nějak vážně očekává. Pokud se ale někdo pokusí machrovat při technické části pohovoru s budoucím technickým šéfem nebo kolegou, tak dofidlal. A je jedno, jestli narazil na Aničku nebo se snaží dostat do IBM.

Tak v tvém případě bych se dam z HR vůbec nebála. Už jenom proto, že patříš k osůbkám, co na ně stojí lovci hlav frontu .

[Yokotashi]

HR je od toho, aby pomohlo vyplnit papiry a dela to dobre.

Predstava, ze se nekdo bude tvarit, ze neco umi a bude se s tim pokouset oblafnout Vojtu mi prijde smesna az zabavna a mozna by stalo za to to natocit na kameru.

[Kyosuke]

Mno, co tak vzpomínám, jeden z těch posledních sebevědomých dostal od Vojty k identifikaci všelijaký zajímavý síťový hardware a užil si docela horké chvilky.

[anicka]

Jo, kdyby jen sitovy... bylo tam par veci, ktere bych taky nedala, a se sitemi nemely moc spolecneho. Ale rikat pred Vojtou, ze se vyznas v hardware...

Nejlepsi byl stary prototyp joysticku, ta deska vypadala spis jak z prastareho radia

[MJ]

No, po pravdě řečeno, někoho, kdo považuje za normální lhát jako když tiskne (ať už v jakékoliv situaci), bych v týmu v žádném případě mít nechtěl.

[Kyosuke]

Jo, jasne. Jenze ta uloha byvala typu "otocte string na miste v libovolnem programovacim jazyce,"

V UTF-8, předpokládám. (A hezky pořešit combining codepointy! To si budu muset cvičně napsat. )

[Filip Jirsák]

Není v takovém případě jednodušší otočit celý svět a ten string nechat, jak je?

[Ladicek]

jednodušší otočit celý svět

In place?

[Kyosuke]

Profíci na to jdou jedině přes inverzi parity prostoru.

[Ladicek]

Ale to potřebuješ prostory hned dva Nebo si to s něčím pletu.

[JS]

Není v takovém případě jednodušší otočit celý svět a ten string nechat, jak je?

Neco jako prehodit smerovy flag na x86?

[Yokotashi]

Kdyz jsem nastupoval do SuSE, tak jsem si se dvema lidmi popovidal o Linuxu, UNIXech a tak ... a bylo. Z toho se zjisti mnohem vic, nez jestli clovek dokaze resit jeden konkretni priklad. Zjisti se, jestli clovek dokaze cist manualy, umi s tim systemem zachazet ... stejne nikdy nikdo neumi to, co bude v jakemkoliv odbornem zamestnani delat. Dulezite je to, jestli ma sanci se to rozumne rychle naucit.

Mozna je to silene, ale myslim, ze kdyby prisel sedesatilety schopny linuxak se zajmem o praci v QA, tak s nim budu od pristiho mesice sedet v kancelari jenomze takovych je malo ...

[Kyosuke]

"hint: ti, co veri na LDAP jsou jeste horsi"

Tak to pěkně děkuju. Co navrhuješ, rsync na /etc/passwd a /etc/shadow?

odfiltrovat vsechny lidi, kteri veri na nutnost pouzivat na kazdou skopicinu relacni databaze

Mno jo, tak tímhle testem bych ještě prošel. Ale co ten člověk, co nacpal do 10.3 databázi zyppu do SQLite? Ten skončil na gilotině?

[MJ]

Co navrhuješ, rsync na /etc/passwd a /etc/shadow?

Třeba vymyslet na to nový protokol, který není dočista praštěný

[Kyosuke]

Já nemám pocit, že by adresáře (alespoň konceptuelně) byly až tak úplně praštěné. Je sice pravda, že tak, jak to vyrostlo, je to hodně nafouklé (ale vzpomeň na X.500, LDAP je pokrok - i když se dá diskutovat o tom, jestli vůbec šlo klesnout ještě níž), jenže pořád ještě zůstává jedna taková docela "nepodstatná" věc - dají se do toho integrovat nemodifikované stranice s Windows, tedy aspoň předstíráním AD DS (na kterém se pracuje ). A dokud velká část světa bude heterogenní nebo dokonce Windows only a já budu chtít centrální správu (ideálně tak, aby mě to nestálo práci navíc, a naopak ji to ušetřilo), tak tam ty uvozovky kolem "nepodstatná" pořád budou. Dtto MasOX. Jo a pak ještě přepsat všechny ty aplikace, co v současnosti LDAP podporují. Ale aspoň fandím lidem kolem Samby 4, ti se tváří, že by se jim aspoň ta serverová část mohla (konečně) podařit docela pěkně (jestli něco takového jde ).

[MJ]

Koncept je správný, ale implementace poněkud scestná. Bohužel si z té X.500 ještě ledacos vypůjčili

Existence windowsového dědictví (asi tak příjemného jako poltergeist v domě) by přeci neměla ovlivňovat volbu protokolu pro zbytek světa. Windows mohou klidně s tím zbytkem komunikovat přes LDAPovou proxy.

[Kyosuke]

Co takhle za Matfyzu jako nějaký ročníkový projekt zadat lidem F(eatherweight)DAP?

[MJ]

Máš ho mít

[Kyosuke]

Uááá!! Teď jen aby mi vydržel v nabídce, než se dostanu po přihlášení příští rok do přislušného ročníku.

[Michal Vyskočil]

Mno jo, tak tímhle testem bych ještě prošel. Ale co ten člověk, co nacpal do 10.3 databázi zyppu do SQLite? Ten skončil na gilotině?

Já vím, ty bys každou skopičinu nacpal do perzistentních Lispovských objektů a to už je naprosto jiná kategorie

[Kyosuke]

Mne-e, v první řadě bych na data Zyppu zkusil použít DataDraw. (Ale jak tak koukám na tu malou tabulku vespod, vedlo by to k dalěí hádce MJe a pana Ponkráce... )

[anicka]

Neboj, já ho kdyžtak přemluvím, že bychom se měli věnovat domácím pracím

[Michal Vyskočil]

Já nemluvil o zyppu, ale obecně

[Ondrej 'SanTiago' Zajicek]

Co navrhuješ, rsync na /etc/passwd a /etc/shadow?

To neni az tak spatny napad. Myslim, ze v mnoha pripadech by reseni zalozene na tomto pricipu mohlo byt lepsi, nez vyuziti LDAP ci jinych podobnych protokolu.

[MJ]

V menších a poměrně homogenních sítích často ano, mimo jiné proto, že při pádu serveru nepřestanou fungovat všechny ostatní stroje.

[Kyosuke]

A co systémy, které passwd ani shadow nemají, a já je stejně chci zaintegrovat do firemní sítě? Stroje s Windows, kapesní terminály... Nikdy bych netvrdil, že to řešení musí nutně být na LDAPu, ale dovedu si představit, že existují firmy, kterým se něco takového může hodit (čti: když softwarové řešení tuhle možnost nenabídne, jejich management software prostě nekoupí a tečka a můžeš se vztekat, jak chceš).

[Ondrej 'SanTiago' Zajicek]

A co systémy, které passwd ani shadow nemají, a já je stejně chci zaintegrovat do firemní sítě?

Distribuovana data mohou byt v nejakem kanonickem formatu a lokalni konfiguracni data se z nej mohou generovat po synchronizaci.

[Filip Jirsák]

Kdybych umel zadat anketu, tak bych polozil jednu jedinou otazku - take povazujete relacni databaze za nesmysl? A vysledek by byl jednoznacny a poradna facka pro cely IT prumysl - max. 5% by odpovedelo kladne.

Pět procent kladných odpovědí na otázku: „Považujete relační databáze za nesmysl?“ by žádná facka pro IT průmysl nebyla – 95 % respondentů, kteří znají smysl relačních databází, to bohatě stačí. Ale když někomu dělá problémy vyjádřit správně i vztah ve dvou po sobě následujících větách, relační databáze pro něj budou asi opravdu problém…

[springer]

s pravdepodobnosti na hranici jistoty bych se odvazil tvrdit, ze jste tu otazku v te pomyslen ankete vubec nepochopil.

[Filip Jirsák]

Z otázky a vašeho odhadu odpovědí plyne, že podle vás maximálně 5 % lidí považuje relační databáze za nesmysl, a tedy (pokud připustíme pouze volbu ano–ne) že minimálně 95 % lidí vidí smysl relačních databází. Což nemůže být facka pro IT průmysl – když lidé relační databáze chtějí (podle vás více jak 95 %), tak jim je nabídne. Pokud jste snad měl na mysli to, že relační databáze nemají vůbec žádný smysl a anketa by ukázala, že o tom IT průmysl neví, pak by to vaše zjištění byla pro IT průmysl ostuda, ne pohroma. A pokud vy nevidíte žádné rozumné použití pro relační databáze, může to být taky znak vašeho malého rozhledu, ne důkaz nesmyslnosti relačních databází.

[Mrkva]

To by me zajimalo, proc jsou relacni databaze nesmysl :)

[freshmouse]

Co otravuješ? Prostě to dad řekl, tak to musí bejt pravda! Copak ti nestačí jeho věk, na kterej tady pořád dělá reklamu, jako jasnej důkaz, že tomu všemu prostě rozumí? Prober se! Oproti němu jsme všichni nuly!

[springer]

delsi dobu pozoruji, ze jste si vytvoril nejakou silnou averzi vuci me osobe. Je to ale nesmysl, takhle se zrat, ja pro vas nejsem zadna konkurence. To ze pisu inteligentnejsi a vtipnejsi prispevky vas urcite nemusi vzrusovat, mlada devcata na to bohuzel uz neleti ...

[freshmouse]

Žádnou averzi jsem si nevytvořil, tu jsem prostě získal...

[anicka]

Relacni databaze se na ledacos hodi... problem je v tom, ze se taky na spoustu veci nehodi ani trochu, ale presto je industry standard je na ne pouzivat.

To mas stejne jako s Javou

I kdyz je pravda, ze u te Javy aspon nemusis resit, kterou drahou implementaci si koupis (a vysvetlovat tem zabednencum, ze nebudes pouzivat postgresql, i kdyz namitaji, ze by Ti bohate stacilo - uz proto, ze ve skutecnosti nepotrebujes ani tu databazi ))

[Miloslav Ponkrác]

Nějak mě přijde, aničko, že přeháníte. Relační databáze jsou príma věc, a to, že se používají na co se nehodí - já takový příklad prakticky neznám. Navíc v databázích je obrovský výběr od malinkých až po obrovské - a řada z nich je zadarmo. Mě by zajímalo pár příkladů, kam se databáze nehodí - a pokud možno významné procento případů, aby to opravňovalo Tvůj strach před databázemi.

Jinak pokud chceš kritizovat něco, co se nadužívá i tam, kde to není potřeba - je v první řadě třeba zmínit XML. XML se stalo takovou módou, že se rve naprosto všude, i kde je zoufale neefektivní. Stalo se to takovou módou, že XML se rve i tam, kde by měly být binární protokoly, nebo kde výhody XML naprosto nemají smysl.

[s0]

nejlepší jsou enterprise technologie, kdy se do nějaké supa dupa databáze kategorie Oracle/DB2 rvou XML do c/blobů a pak se neustále parsují tamtéž. Připravte vejce, budeme smažit volská oka...

[Miloslav Ponkrác]

Ano, a protože někdo roznáší AIDS je sex a milování úplně špatné a mělo by se totálně zrušit.

Miluju ty argumenty, kdy někdo použije kladivo jako frézu a na tomto příkladě se dokazuje, že kladivo i fréza jsou špatné a naprosto zbytečné nástroje, které nejsou k ničemu potřeba.

[xkucf03]

rvou XML do c/blobů

Možná ti uniklo, že vyspělé relační databáze mají vlastní datový typ pro XML a dá se s ním pracovat (XPath, XQuery, transformace...) na úrovni databáze a není potřeba si z clobů vytahovat data do aplikace a zpracovávat je až tam.

[MJ]

A co že je na takové struktuře vlastně relačního?

[s0]

pánové, já se právě tím, že udržuju relační db v chodu a ochraňuju je před pekelnými útoky aplikačních programátorů, živím. Jo, a rdbms jakožto technologii mám celkem rád.

[Filip Jirsák]

Relační databáze jsou príma věc, a to, že se používají na co se nehodí - já takový příklad prakticky neznám.

Znáte Firefox 3? Tak vidíte…

[Miloslav Ponkrác]

Ano, a nedávno jsem s údivem konstatoval, že pracuje na mém stroji několikanásobně rychleji. A tak jsem chvíli pátral a zjistil, že namísto XML souborů data ukládá do sqlite relační databáze. Takže ano, Firefox 3 je příkladem, kde se relační databáze báječně hodí, a její použití velmi zlepšilo program.

[xkucf03]

Já zase nechápu tu tvoji averzi ke XML. Teď používám XML i k ukládání dat ve formě klíč-hodnota. Někdo by si řekl, že na tak primitivní věc ani XML není potřeba, ale hodí se: dávám SQL příkazy do zvláštních souborů (aby nebyly namatlané ve zdrojáku) a XML mi umožňuje si tyto SQL příkazy pojmenovat a zachovat u nich přehledné formátování (víceřádkové). Načtení a parsování takového XML je pak záležitost asi na dva řádky - protože parser už existuje a nemusím si ho psát jako u nějakého vlastního "efektivního" binárního formátu.

(ale musím uznat, že je často vidět i neefektivní používání XML: např. když si autor nevytváří vlastní DTD/Schéma i když je to vhodné a místo toho složitá data nacpe do struktury klíč-hodnota)

[Miloslav Ponkrác]

Já nemám averzi k XML. Mám averzi k přehnanému používání XML, nic víc a nic méně.

Důvod proč se XML nadužívá je prostý - jednoduché parsery. Pokud se do XML ukládá něco jednoduché, pak obrovská režie parseru je zanedbatelná. Pokud ovšem stoupne počat dotazů na XML, začne být zle, a často se to řeší duplicitním protokolem, který existuje paralelně.

Příklad: Starý binární CORBA protokol snese velkou zátěž, ale totéž přes SOAP, XML-RPC, či protokoly web services neuděláte ani dvacetinu té zátěže na stejném stroji. Proč? Protože režie parseru XML.

Příklad: jabber, XML protokol, a nutnost k němu paralelně jiným způsobem hnát třeba video data, protože XML už by nedokázal tuhle funkčnost zařídit.

Zrovna Váš příklad mi přijde jako ne úplně šikovným použítím XML. Narval bych SQL dotazy včetně víceřádkového formátování a pojmenování taktéž do relační databáze a kód na jejich obsluhu by byl naprosto primitivní. I když uznávám, že XML také vyhoví.

[Filip Jirsák]

Důvod proč se XML nadužívá je prostý - jednoduché parsery. Pokud se do XML ukládá něco jednoduché, pak obrovská režie parseru je zanedbatelná. Pokud ovšem stoupne počat dotazů na XML, začne být zle, a často se to řeší duplicitním protokolem, který existuje paralelně.

Příklad: Starý binární CORBA protokol snese velkou zátěž, ale totéž přes SOAP, XML-RPC, či protokoly web services neuděláte ani dvacetinu té zátěže na stejném stroji. Proč? Protože režie parseru XML.

Ono taky záleží na tom, jak je ten parser a celý proces zpracování postaven. Jestli se z celého dokumentu staví DOM ve kterém se pak hledá přes XPath, a to celé zpracovává parser s podporou všeho možného i nemožného konstruovaný tak, aby odhalil co nejvíce chyb dokumentu (místo aby to po první chybě zabalil), pak to samozřejmě bude trvat. Ale je možné XML také proudově přetransformovat do nějaké vnitřní reprezentace, a pak jediná režie navíc oproti binárnímu protokolu bude složitější práce s řetězci oproti jednoduché manipulaci s čísly o známé velikosti.

Příklad: jabber, XML protokol, a nutnost k němu paralelně jiným způsobem hnát třeba video data, protože XML už by nedokázal tuhle funkčnost zařídit.

XML je jazyk pro značkování textů, někdy ještě snese použití jako jazyk pro popis strukturovaných dat. Ale pokoušet se jej jakkoli skloubit s videem je nesmysl, a že to nejde není problém XML. Ať by měl jabber protokol jakýkoli, nebude to jeden protokol pro přenášení textových zpráv a stavových informací, a ten samý protokol i pro přenos videa. (Tedy pokud to nebude „jeden“ protokol s jedním názvem, který ve skutečnosti bude v sobě ukrývat dva odlišné protokoly.)

[Miloslav Ponkrác]

Ale je možné XML také proudově přetransformovat do nějaké vnitřní reprezentace, a pak jediná režie navíc oproti binárnímu protokolu bude složitější práce s řetězci oproti jednoduché manipulaci s čísly o známé velikosti.

Jinak řečeno už se nebude jednak o XML, ale o binární data. Tudíž jsme někde úplně jinde.

(Tedy pokud to nebude „jeden“ protokol s jedním názvem, který ve skutečnosti bude v sobě ukrývat dva odlišné protokoly.)

Tak v tom případě neexistuje jeden protokol. Například můj binární protokol má v sobě "protokol" pro uložení int8, jiný "protokol" pro uložení int16, jiný "protokol" pro int32, a jiný "protokol" pro string, atd...

Myslím, že se to nemusí přehánět - prostě binární protokol (jeden jediný) snadno vyhoví i pro přenost video data stejně jako čehokoli jiného, protože neprochází režií XML parseru. Jediný důvod, proč nemůže přenášet XML video není v tom, že by principiálně nemohl - mohl. Ale režie XML parseru (i toho nejjednoduššího) je taková, že bychom si na jabber klienta museli zakoupit IBM Blue Gene.

[Filip Jirsák]

Jinak řečeno už se nebude jednak o XML, ale o binární data. Tudíž jsme někde úplně jinde.

Zatímco když se to pošle binárně, program si to stejně převede do svého formátu, takže ten binární protokol je taky k ničemu. Vlastně každý přenosový formát/protokol je k ničemu, protože program si to pak musí převést do vnitřní reprezentace.

XML je formát pro přenos dat, žádný program nepoužívá jako vnitřní reprezentaci XML. Používá třeba DOM, ale DOM není XML.

Myslím, že se to nemusí přehánět - prostě binární protokol (jeden jediný) snadno vyhoví i pro přenost video data stejně jako čehokoli jiného, protože neprochází režií XML parseru. Jediný důvod, proč nemůže přenášet XML video není v tom, že by principiálně nemohl - mohl. Ale režie XML parseru (i toho nejjednoduššího) je taková, že bychom si na jabber klienta museli zakoupit IBM Blue Gene.

Pokud „binární protokol“ říkáte čemukoli, co nejde na první pohled přečíst, pak máte pravdu. Jinak je to pěkný nesmysl – pro přenos krátkých bloků dat se hodí protokol, který na začátku pošle hlavičky, podle kterých se bude parser orientovat, a pak už posílá jenom data. Pro streamování videa ale potřebujete takový protokol, který umožní režijní data a samotný přenášený obsah míchat (protože třeba těžko může vysílající strana celý obsah bufferovat, aby zjistila, jak je vlastně dlouhý, a mohla délku dat poslat na začátku v metadatech). Jakou režii bude mít třeba XML parser, když bude vstupní proud bajtů skenovat, zda tam náhodou není konec CDATA? Zatím o režii XML parseru mluvíte jako kdyby byla způsobena pouze přítomností tří písmenek XML v jeho názvu – a prostě cokoli, kde se vyskytuje XML, musí být zřejmě pomalé.

[MJ]

Pokud „binární protokol“ říkáte čemukoli, co nejde na první pohled přečíst, pak

… jsou některé soubory v XML dokonale binární

[xkucf03]

Starý binární CORBA protokol snese velkou zátěž, ale totéž přes SOAP, XML-RPC, či protokoly web services neuděláte ani dvacetinu té zátěže na stejném stroji.

CORBu jsem zrovna nedávno použil. Spokojenost. Ale byla to tak jednoduchá C/S aplikace, že na tom ani není poznat, zda je to rychlé nebo pomalé. Nějaký benchmark o tom dvacetinásobném výkonu by nebyl?

jabber, XML protokol, a nutnost k němu paralelně jiným způsobem hnát třeba video data, protože XML už by nedokázal tuhle funkčnost zařídit.

Tak jako tak by sis navazoval paralelní TCP* spojení, aby si lidé mohli nerušeně psát textové zprávy a přitom probíhal např. přenos souboru. Soubory/video/zvuk by do XML nikdo necpal, ale že do něj autoři Jabberu zabalili textové zprávy, na tom nevidím nic špatného. V IT se klade důraz na znovupoužitelnost, aby se neztrácel čas psaním stejného kódu znovu a znovu, proto se používají databáze, knihovny,... a XML parsery. Ušetřená práce použitím standardního parseru místo toho, aby se pro každý jazyk psala implementace binárního protokolu, zřejmě vyvažuje nevýhody (zanedbatelně větší přenosy dat).

Narval bych SQL dotazy včetně víceřádkového formátování a pojmenování taktéž do relační databáze

To mi připadá jako relační extremismus Stejně bych přece musel mít někde uložený SELECT, který mi z DB vytáhne ty další SELECTy. Ale nápad je to zajímavý.

*) či jiné.

[Miloslav Ponkrác]

Nějaký benchmark o tom dvacetinásobném výkonu by nebyl?

Kdysi před lety jsem to měřil. Bohužel to nebyl dvacetinásobek, ale dostal jsem se v reálu na nějaký plus mínus stonásobek výkonu CORBy oproti SOAPu.

Tak jako tak by sis navazoval paralelní TCP* spojení, aby si lidé mohli nerušeně psát textové zprávy a přitom probíhal např. přenos souboru.

Proč? Myslím, že by šel velmi snadno udělat protokol, který po jednom spojení nerušeně přenese vše, tedy psát textové zprávy, a na pozadí přenost ostatního. Je to jen otázka vhodného časování, priorit a uspořádání dat v datovém toku po síti. Ostatně stejně to z počítače jde po jednom stejném drátě a dělí se to o jednu síťovou propustnost, ne?

V IT se klade důraz na znovupoužitelnost, aby se neztrácel čas psaním stejného kódu znovu a znovu, proto se používají databáze, knihovny,... a XML parsery.

Jak kdy. Třeba u psaní low level věcí se klade větší důraz na efektivitu a rychlost, a znovupoužitelnost jen tehdy, pokud to toto příliš neohrozí (což bývá velmi často, ale nemusí to jít spolu dohromady).

Třeba zrovna taková databáze je v jádře psaná hlavně tak, aby byla rychlá a efektivní. Tudíž nikdo po create table nevytvoří třeba XML soubor na disku, protože tvůrce databáze má hotový znovupoužitelný parser, ale prostě si ta data hlídá sám.

A stejně tak TCP protokol byl vytvořen s ohledem na rychlost. Nikoho ani nenapadlo do toho cpát nic jiného, než binární data do hlavičky. Atd..

Ušetřená práce použitím standardního parseru místo toho, aby se pro každý jazyk psala implementace binárního protokolu, zřejmě vyvažuje nevýhody (zanedbatelně větší přenosy dat).

Upřímně, kdybych stejně jako onen student, co stvořil jabber dělal diplomku, tak bych také použil XML. Prostě udělat a zahodit, případně nahradit lepším protokolem, pokud bych to chtěl skutečně použít v praxi.

Takže toho tvůrce jabberu chápu a dělal bych to stejně. XML je dobrý nástřel a skvělě rychlý vývoj. Bohužel kromě zpráv a pár pomalých věcí už stejně používá jiné protokolym, tedy NĚKOLIK protokolů a nakonec programátor v důsledku IMPLEMENTUJE VÍCE, a stráví nad vývojem programu více času, než kdyby implementoval pouze JEDEN binární protokol.

[Kyosuke]

Proč? Myslím, že by šel velmi snadno udělat protokol, který po jednom spojení nerušeně přenese vše, tedy psát textové zprávy, a na pozadí přenost ostatního. Je to jen otázka vhodného časování, priorit a uspořádání dat v datovém toku po síti. Ostatně stejně to z počítače jde po jednom stejném drátě a dělí se to o jednu síťovou propustnost, ne?

Jo, říkalo se tomu ATM.

[xkucf03]

Ostatně stejně to z počítače jde po jednom stejném drátě a dělí se to o jednu síťovou propustnost, ne?

Stejně tak všechny soubory skončí jako bajty na /dev/sda, proto nemusíme používat souborové systémy a programy mohou pracovat rovnou s raw diskem V případě toho protokolu by museli vývojáři znova a znova implementovat mechanismus jak poskládat pakety za sebe, jak je označovat, který patří do kterého proudu. A přitom to jde tak snadno - otevřít si dva TCP porty a o poskládání paketů dohromady se nám postará vrstva, která už je dávno napsaná.

pouze JEDEN binární protokol.

To je iluze, ten jeden protokol by byl velmi složitý a jedinečný (nový). Naopak v případě těch více protokolů se používají už často hotové (a praxí prověřené a vyladěné) kusy kódu, algoritmy a knihovny, které stačí jen poskládat dohromady a vývoj je proto efektivnější.

[MJ]

V IT se klade důraz na znovupoužitelnost, aby se neztrácel čas psaním stejného kódu znovu a znovu, proto se používají databáze, knihovny,... a XML parsery. Ušetřená práce použitím standardního parseru místo toho, aby se pro každý jazyk psala implementace binárního protokolu, zřejmě vyvažuje nevýhody (zanedbatelně větší přenosy dat).

Lidé už jen nějak zapomněli na to, že často mohou použít tak triviální protokol, že jeho naparsování bude jednodušší než zavolání XML parseru

[xkucf03]

O tom XML Jabberu vs. binárním ICQ jsme několikrát diskutovali na Rootu (1, 2). Každý mele to svoje pořád dokola, ale jediné přiložené měření hovoří jasně ve prospěch Jabberu: Naklady na jabber v siti Vodafone. Tedy ve prospěch XML prohnaného skrz zlib.

[Kyosuke]

Však taky pan Ponkrác s největší pravděpodobností hovoří o firemním gigabitu a dvou komunikujících aplikačních strojích na LAN. V případě Internetu se s velkou pravděpodobností úspora šířky pásma tímhle způsobem projeví natolik výrazně, že případné neefektivity velmi umně zamaskuje.

[Ondrej 'SanTiago' Zajicek]

a nutnost k němu paralelně jiným způsobem hnát třeba video data

Ona audio a video data se zenou paralelne i k jednodussim protokolum (treb SIP) primarne kvuli tomu, ze se nezenou pres TCP, ale pres UDP/RTP.

[Kyosuke]

Velké štěstí je, že relační model je natolik jednoduchý, že není zapotřebí ani to SQL. Firebirdí GDML, haskellí HaskellDB a podobné věci ukazují, že to jde i jinak, a žádné "matlání SQL do zdrojáku" v podstatě není zapotřebí.

Mimochodem - "Načtení a parsování takového XML je pak záležitost asi na dva řádky - protože parser už existuje a nemusím si ho psát jako u nějakého vlastního "efektivního" binárního formátu" - tohle bych viděl jako příznak závažného brain damage. Nepředávkoval jste se v posledních dvou letech velkým mnostvím Javy? Každý aspoň trošku rozumný programovací jazyk umožňuje snadný výpis svých datových objektů v readable formátu - lispovské WRITE a READ, haskellovské třídy Show a Read... Osobně jsem zaznamenal, že lispovský READ je nad daty isomorfními ke XML (stylem (element ...) místo <element> ... <element>, a dál pokračovat rekurzivně) asi desetkrát rychlejší než Expat, údajně nejrychlejší XML parser. A nemusel jsem si nic psát, READ ze souboru a tečka.

[xkucf03]

asi desetkrát rychlejší než Expat, údajně nejrychlejší XML parser

Vzhledem k tomu, že SQL v XML souborech jsou náhradou za konstanty uvnitř kódu, stačí je načíst jen jednou při inicializaci třídy. I desetkrát vyšší/nižší výkon je pak stejně irelevantní, protože v obou případech je to načtené hned.

Nepředávkoval jste se v posledních dvou letech velkým mnostvím Javy?

Javu já rád

umožňuje snadný výpis svých datových objektů v readable formátu

Např. v Javě se tomu říká serializace, případně serializace do XML.

[Kyosuke]

Vzhledem k tomu, že SQL v XML souborech jsou náhradou za konstanty uvnitř kódu, stačí je načíst jen jednou při inicializaci třídy. I desetkrát vyšší/nižší výkon je pak stejně irelevantní, protože v obou případech je to načtené hned.

A já reagoval čistě na "nemusím si ho psát jako u nějakého vlastního "efektivního" binárního formátu" já si ho 1) nemusím psát (ani používat XML parser), 2) je to rychlé a 3) jednoduše se to používá, a to tak nějak všechno současně.

Javu já rád

A někteří lidé zase rádi elektrický proud v genitáliích. De gustibus non disputandum est.

Např. v Javě se tomu říká serializace, případně serializace do XML.

Nevšiml jsem si, že by Java umožňovala snadný a lidsky čitelný výpis do textu, což je to, o čem mluvím. A pak lidé dělají takové věci, jako že hážou SQL do XML a sami sobě to omlouvají tím, že je to vlastně jednoduché a dobré a skvělé...

[MJ]

Relační databáze jsou príma věc, a to, že se používají na co se nehodí - já takový příklad prakticky neznám.

Už jsem o dvou psal o pár příspěvků níže: stromy (nebo obecně grafy) a textová data.

Jinak pokud chceš kritizovat něco, co se nadužívá i tam, kde to není potřeba - je v první řadě třeba zmínit XML.

To je samozřejmě pravda …

nebo kde výhody XML naprosto nemají smysl.

… hlavně proto, že ony "výhody XML" jsou značně imagimární. Respektive všechny z nich mají i obyčejné S-expressions.

Především mi ale přijde, že se spousta lidí naučila považovat relační DB i XML za magický hadí olej, kterým lze vyléčit všechno, a jaksi o tom zapomněli přemýšlet.

[xkucf03]

... a textová data.

Textová data ale neexistují někde sama o sobě, ve vzduchoprázdnu. Mají vazby na jiná data, struktury, což se dá vyjádřit cizími klíči. Proto je dost dobré řešení dávat strukturované texty v XML do DB (což odpovídá i na tvoje předchozí otázku, co je na tom relačního).

[MJ]

Textová data především potřebujete reprezentovat tak, aby se v nich dalo efektivně hledat. To relační model neumí.

[xkucf03]

K efektivnímu hledání je potřeba indexace - a pak je jedno, jestli indexujeme soubory na disku nebo vybrané sloupečky z databáze.

[MJ]

Jinými slovy: "Data musíme uložit dvakrát. Jednou, aby vypadala jako relace, podruhé, aby se v nich dalo hledat."

To je jenom mýtus. Často můžete zvolit takovou formu uložení, ve které půjde přímo hledat efektivně, bez jakýchkoliv indexů.

[Robo]

Často můžete zvolit takovou formu uložení, ve které půjde přímo hledat efektivně, bez jakýchkoliv indexů.

priklad?

[xkucf03]

Často můžete zvolit takovou formu uložení, ve které půjde přímo hledat efektivně, bez jakýchkoliv indexů.

Jestli nekecáš, tak klobouk dolů, objevil jsi něco úžasného, co nám ušetří spoustu práce. Ale spíš bych řekl, že jen tak plácáš.

[MJ]

Neobjevil, to už dávno učinili jiní, jen většina databázníků zamrzla kdesi v 70. letech a nevšimla si, že na poli datových struktur od té doby vyrostla spousta nových zajímavých odrůd.

Když se budu držet příkladu se stromy, který jsem už načal, nabízí se dvě velice pěkné reprezentace, totiž Sleator-Tarjanovy stromy (nazývané také Link-Cut Trees) a ET-stromy. V obou případech zvládnete v čase O(log n) jak přepočítání struktury po změně reprezentovaného stromu (přidání nového vrcholu, spojení dvou vrcholů hranou, odebrání hrany, změna kořene atd.), tak poměrně široký repertoár dotazů: lokální dotazy (přímé okolí vrcholu), hierarchické dotazy ("je vrchol v daném podstromu?") a spoustu dalších. ST-stromy navíc umí operace s cestami ("jaká je vzdálenost těchto dvou vrcholů?", "jaká hrana má na cestě mezi dvěma vrcholy největší ohodnocení?"), ET-stromy lze velice pěkně reprezentovat i na disku.

Jestli si chcete počíst, svého času jsem o tom něco málo napsal.

[xkucf03]

Měl jsem za to, že když se bavíme o textech a hledání, jde o fulltextové hnedání (tam se bez indexace těžko obejdeme). Pravda, že stromy a grafy jsou něco jiného, na co relační DB nejsou stavěné.

[Robo]

hovori sa tomu object-relational model ;)

[MJ]

Tím, že něco pojmenujete, ještě nezařídíte, aby to existovalo a fungovalo efektivně

[Daniel Kvasnička ml.]

Ne, ze by RDBMS byly nesmysl, nevim proc tak radikalni nazor. Ale ze se do nich dneska pokousi lidi nacpat soustu dat, ktera se do nich svou povahou nehodi, to je celkem evidentni. Vsak nativni XML ci objektove databaze pomalu ziskavaji taky svoje misto na slunci. Jen se nam u nich nesmi stat to same co u RDBMS -- ze do nich budem cpat co do nich nepatri.

Nakonec si neodpustim zaspamovat jednim ze svych oblibenych citatu, sem se celkem hodi.

Roughly 80% of the world’s data cannot plausibly be stored in a relational database. The 20% that does fit there is important enough that we’ve spent the last 20 years stuffing it into relational databases and doing interesting things with it. I’m still doing a lot of that. But there’s a lot more data out there that doesn’t look like tables than does. -- Elliotte Rusty Harold

[Luk]

ze do nich budem cpat co do nich nepatri

Nejlepší jsou takoví, co cpou do jednoho pole/sloupce tabulky hromadu nestrukturovaných dat, ve kterých se pak aplikaci přehrabuje a hledá tam, co potřebuje

[thingie]

Nativní XML databáze, no, to bude pan autor asi nadšený, kdo se toho zase chopil (Jak se to říká, z deště pod okap?)

[Miloslav Ponkrác]

Problém vůči relačním databázím je jednoduchý - relační databáze mají jednoduchý princip, jsou propracované vývojem - a jednoduchost naprosto vždy znamená vyšší výkon, vyšší rychlost, vyšší spolehlivost.

Do relační databáze se v zásadě dá nacpat všechno a dá se to nacpat v takové struktuře, že to bude makat setsakra rychle i na obrovských datech. Jak XML, tak objektové databáze vám v krajních případech - hlavně potřebě vysokého výkonu zoufale selžou. Viz výkon jednoduchého Unixu a složitých Windows ve vysokých zátěžích.

Nemůžu si pomoct, ale XML databáze je prostě snaha učesat databázi na míru XML, objektová databáze zase OOP programování. Zatímco XML je ještě jednoduchý a poměrně univerzální princip, a možná pro 1% případů by se mohlo hodit, u OOP jde podle mě o přílišnou složitost, aby to univerzálně mohlo být stejně užitečné - hlavně při potřebě vysokého výkonu.

Podle mě jsou relační databáze báječný vynález - a jediné co jim lidi zazlívají, že relační přístup je jiný, než ten, ve kterém běžně programují. Ale stejně tak, jako nikdo nedělá procesor s objektovým strojákem, nebo procesor s XML instrukcemi, protože by to bylo pomalé, žravé a zoufale neefektivní, navíc užitečné jen pro velmi málo případů - tak stejné to bude s databázemi.

[MJ]

Do relační databáze se v zásadě dá nacpat všechno a dá se to nacpat v takové struktuře, že to bude makat setsakra rychle i na obrovských datech.

Že jsem tak smělý, jak byste tam nacpal strom, abyste na něm uměl efektivně odpovídat na strukturální dotazy? (Tj. třeba dotazy typu "je x potomkem y?")

Nebo třeba textové dotazy na podřetězce?

[Jsem dalek toho, abych se zastával XML databází, ale přijde mi, že ačkliv relační databáze jsou skvělé univerzální kladivo, člověk by si měl uvědomit že ne všechno na světě jsou hřebíky ]

[Ladicek]

Ukládání stromových struktur do databáze ještě jde (obecný graf bude asi horší). Mne by spíš zajímalo, jak do relační databáze (rozumně!) uložit entitu o předem neznámém počtu atributů předem neznámého typu (To není až taková absurdita. Málokdy ví člověk předem, co všechno za atributy budou jeho objekty mít.)

[Kvakor]

Že jsem tak smělý, jak byste tam nacpal strom, abyste na něm uměl efektivně odpovídat na strukturální dotazy? (Tj. třeba dotazy typu "je x potomkem y?")

Zrovna tohle se resi celkem jednodusse, protoze v klasicke implementaci ma kazdy potomek v sobe odkaz na sveho predka. Vice viz Stromy v SQL.

[Kyosuke]

"Celkem jednoduše"? Jestli se to řeší "celkem jednoduše", proč se do relačních databází extra kvůli tomuhle přidávají fíčury (typu CTE), aby se to urychlilo na rychlost nikoli hlemýždí? A ten odkazovaný článek také jen dokazuje, že to je v podstatě hack a že na takové věci je lepší použít třeba nějakou slušnou objektovou databázi. Nicméně ano, pokud jediné, co člověk má k dispozici, je relační databáze, opravdu může všechno být až podezřele podobné tabulce.

[MJ]

Zrovna tohle se resi celkem jednodusse, protoze v klasicke implementaci ma kazdy potomek v sobe odkaz na sveho predka.

To jsme se asi nepochopili – já nemyslel přímého potomka, ale to, že se x nachází kdekoliv v podstromu, jehož kořenem je y.

Vice viz Stromy v SQL.

No právě – ani jedna z tam popisovaných reprezentací není efektivní: sebereferenční tabulky neumí to, co jsem popisoval, genealogické stromy zabírají v nejhorším případě kvadratický prostor (a tedy potřebují i kvadratický čas na vytvoření; třeba když je celý strom degenerovaný do cesty) a DFS stromy sice podporují efektivní dotazy, ale pro změnu je nejde rychle přepočítat při změně struktury.

Přitom existuje hned několik efektivních reprezentací stromů (třeba Sleator-Tarjanovy stromy nebo ET-stromy), které umí všechny běžné dotazy i změny struktury provést v čase O(log n). Jen je jaksi potřeba přestat věřit na to, že svět je množina k-tic

[Daniel Kvasnička ml.]

možná pro 1% případů by se mohlo hodit

Dnes v dobe masivniho nastupu XML v oblasti kancelarskych formatu? Obecne pro dokumentove orientovane zalezitosti je XML db jako delana. Pokud chcete mit moznost efektivne se dotazovat na jednotlive informace, zapomente na oddelene ukladani dokumentu nekde na disk nebo nedej boze do RDBMS. Pokud to mate ulozene vse v XML kontextu, zveda se vam rapidne produktivita pri miningu z takovych dat.

Stejne tak CMS je podle me idealnim prikladem. Ukladat jednotlive stranky webu pri hierarchicke povaze jejich vztahu jako samostatne bloky dat do RDBMS je sice dneska drtive prevazujici praktika, ale IMHO odporujici povaze toho pripadu samotneho. A je to jeste vice umocneno tim, ze ty stranky jsou fakticky XML, tedy kdyz jde o XHTML. A mate to same, co v prvnim pripade. Velice efektivne dotazovatelna data v kontextu. (O kriklavosti ukladani menu stranek do RDBMS stylem id & parent_id uz ani nemluvim...).

Ale stejně tak, jako nikdo nedělá procesor s objektovým strojákem, nebo procesor s XML instrukcemi

IBM ma jednu takovou hracku...

[Ladicek]

IBM ma jednu takovou hracku...

Tak tohle je fakt masakr Jinak všechno jde…

[Daniel Kvasnička ml.]

Tak tohle je fakt masakr

Ze jo? ...uz vim, na cem postavim pristi verzi svych osobnich stranek

[Miloslav Ponkrác]

Obecne pro dokumentove orientovane zalezitosti je XML db jako delana.

Obecně pro každý problém můžete vymyslet speciální formát pro něj jako dělaný.

Problém je, že relační databáze jsou tak obecný princip, a přitom tak jednoduchý, a tím pádem výkonný a rychlý a spolehlivý, že je to univerzální koncept. Přesně stejný koncept mezi opračními systémy se našel Unix - jednoduchý, tím pádem výkonný, rychlý a spolehlivý.

Můžete samozřejmě vymýšlet řadu speciálních formátů, stavět si nad nimi své formátové databáze - nic Vám nebrání. Ale bude to užitečné jen v malém procentu případů.

Pokud to mate ulozene vse v XML kontextu, zveda se vam rapidne produktivita pri miningu z takovych dat.

He he he he, to pouze v případě, že XML instanci, tedy tagy a atributy máte vymyšlené v dokumentu tak, aby to nebylo příliš messy pro tento účel (což je v případě XML převažující případ bohužel) - a pak Vám pro data mining nejsou moc platné, nebo naprosto minimálně. I když teoreticky máte naprostou pravdu, prakticky to platí dost málo.

Stejne tak CMS je podle me idealnim prikladem. Ukladat jednotlive stranky webu pri hierarchicke povaze jejich vztahu jako samostatne bloky dat do RDBMS je sice dneska drtive prevazujici praktika, ale IMHO odporujici povaze toho pripadu samotneho.

Aha, už chápu, proč prosazujete XML, a proč tu všichni tak nenávidí relační databáze. Protože jste jako ženské, které neví co chtějí a nedají pokoj dokud to nedostanou. Tak vězte, že pokud chci stránky pouze zobrazovat, pak je takovéto uložení stránek v relační databázi to nejlepší a přesně to co potřebuji. Je to špičkové řešení. Pokud chci stránky pouze zobrazovat, případně strukturálně a fulltextově prohledávat - je daleko lépe uložit stránku v relační databázi, a to je přesně to co většina systémů dělá. XML databáze Vám nijak moc situace nezlepší, a pokud maličko, pak zase kredit více, než bohatě ztratí na tom, že CML potřebuje ukládat i relační data - neboť v té databázi je víc, než jen stránky dokumentů, abuy bylo jasno.

A je to jeste vice umocneno tim, ze ty stranky jsou fakticky XML, tedy kdyz jde o XHTML.

Ale no tak. XHTML je sice teoreticky XML, ale fakticky tam strukturální informace jsou naprosto minimální.

A znovu, zamýšlíte se někdy nad tím, co s těmi dokumenty chcete dělat? Vaše nesmyslné tvrzení, že pro "dokumenty je lepší XML databáze, než relační" je blbost. Zapomínáte na kontext, co s těmi dokumenty chcete dělat. Pokud množinu požadovaných akcí s dokumentem, které potřebujte s přehledem vykonáte nad relační databáz a XML Vám nic navíc nepřinese - proč nasazovat XML databázi?

Celý ten Vás data minimg naráží na jednu věc. Kancelářské dokumenty zkrátka nevytváří datový odborník ani statistik. Vezměte si třeba jen, jak mnoho sekretářek v textovém procesoru odstance dělá mezerami, a nanutit je k používání stylů je často nadlidský výkon. Nakonec i pro firmu se kvality sekretářky měří jinými kvalitami, a řada dokumentů musí hlavně vizuálně vypadat - strukturálně je to jedno.

Pokud nakonec sekretářku zaučíte, narazíte na to, že z jiných firem Vám budou chodit dokumenty od jiných sekretářek, zase jinak formátované, a s řadou strukturálních a typografických chyb.

Takže nakonec zjistíte, že celý data mining z dokumentů a teoretický zisk z něho je blízký nule. A pak zjistíte, že je lépe mít dokument v relační databázi, neboť XML Vám toho mnoho nepřinese, pokud vůbec něco. Něco jiného je samozřejmě, pokud si data tvoříte sami, nebo generuje je automaticky bezchybný program a zajistíte si nějaký význam - ale i pak význam dat je často lépe vyjádřen relační databází, než XML.

Nemůžu si pomoci, ale XML databáze moc užitečné nejsou. Kromě velmi řídkých speciálních případů.

[Daniel Kvasnička ml.]

Tak vězte, že pokud chci stránky pouze zobrazovat, pak je takovéto uložení stránek v relační databázi to nejlepší a přesně to co potřebuji.

Jenze to je fatalne chybny predpoklad Takhle to bylo mozna v prvni polovine 90. let. Dneska informace na netu nejsou jen od toho, aby se proste zobrazovaly obycejnym brouzdanim po strankach. Lidi potrebujou v te brutalni informacni zmenti hledat a najit.

Pokud chci stránky pouze zobrazovat, případně strukturálně a fulltextově prohledávat - je daleko lépe uložit stránku v relační databázi, a to je přesně to co většina systémů dělá.

Ale notak. Co udelate, kdyz budete potrebovat ty stranky prohledavat stylem "najdi mi stranku, kde je slovo 'xyz'"? RDBMS vam nerozlisi co je markup a co data. Kdyz budete mit tag <xyz>, tak vam to na nem shori. Budete si muset napsat berlicky, kterymi tohle budete obchazet.

A pak druhy pripad, uz uplne nevhodny pro RDBMS, je kontextove citlive prohledavani. Tzn. najdi mi stranku, ktera obsahuje 'xyz' a nektery z jejich predku ma v nazvu 'abc'. To same co prvni pripad + dalsi problem. A ja? Napisu primitivni jednoradkovy XPath vyraz

Ale no tak. XHTML je sice teoreticky XML, ale fakticky tam strukturální informace jsou naprosto minimální.

Ale to je irelevantni. Dulezite je, ze je lze diky XML slepit dohromady do jednoho kontextu. Ulozeni v XML proste odrazi realitu toho, jak je to ve skutecnosti. Stranka 'Kontakty' patri pod 'O firme' a taky to tak je. Ne, ze lezi nekde pohozene vedle sebe spojene pres nejaky cizi klic. To neni prirozene usporadani. Ta data proste nemaji tabulkovou strukturu.

A znovu, zamýšlíte se někdy nad tím, co s těmi dokumenty chcete dělat?

Ano, a prave proto si myslim, ze nativni XML db jsou relevantni pro tyhle ucely

Pokud množinu požadovaných akcí s dokumentem, které potřebujte s přehledem vykonáte nad relační databáz

Vykonate. Vykonate vsechno. Ale ne s prehledem.

Celý ten Vás data minimg naráží na jednu věc. Kancelářské dokumenty zkrátka nevytváří datový odborník ani statistik.

Ale to je uplne irelevantni namitka. Me jde prece o informace. Ty dokumenty si muze psat jak chce, pokud dodrzi format, tedy pokud bude vse napr. v ODF. Kdyz bude formatu vice, tak se to rozlisi do kolekci, ktere je ale mozne s dnesnimi XML nastroji stale udrzet v kontextu. Ano, bude problem, kdyz budu chtit hledat data, kdy budu predpokladat, ze jsou v tabulce a ony budou nekde odbouchane mezerami. Ale i tak mam vzdy nejakou sadu elementu, u kterych vim, ze se tam ta data muzou objevit a ze nad nimi muzu hledat.

A casto je to opravdu tak, jak rikate, ze si data tvorim sam. Firma ma prece sve formulare na faktury, smlouvy a ja nevim co...

Nemůžu si pomoci, ale XML databáze moc užitečné nejsou. Kromě velmi řídkých speciálních případů.

Tak to vysvetlujte treba Mark Logicu a jeho klientum...

[Miloslav Ponkrác]

Dneska informace na netu nejsou jen od toho, aby se proste zobrazovaly obycejnym brouzdanim po strankach. Lidi potrebujou v te brutalni informacni zmenti hledat a najit.

A fatálně chybný předpoklad je, že nasazení XML databáze Vám automaticky toto zařídí.

Ale notak. Co udelate, kdyz budete potrebovat ty stranky prohledavat stylem "najdi mi stranku, kde je slovo 'xyz'"? RDBMS vam nerozlisi co je markup a co data. Kdyz budete mit tag <xyz>, tak vam to na nem shori. Budete si muset napsat berlicky, kterymi tohle budete obchazet.

A znovu? Jak seženete ty spousty dokumentů pečlivě otagované? Obávám se, že tohle právě je utopie, kteoru nechcete vidět.

A druhé věc je, že ani s XML databází, ani s relační databází se obvykle nepracuje přímo, ale přes aplikaci. V praxi to tak je - neviděl jsem sekretářku s příkazovým řádkem se spuštěným mysql -h mysql.firma.cz -u sekretarka dokumenty, jak do toho sází SQL příkazy. A obávám se, že totéž bude platit i pro XML databázi. A na druhé straně, databáze, která přechroustá a rozliší tagy jde napsat i s prostředky pouhého databázového serveru. Ony relační databáze nejsou jen tupým skladištěm dat, víme?

Ale to je irelevantni. Dulezite je, ze je lze diky XML slepit dohromady do jednoho kontextu. Ulozeni v XML proste odrazi realitu toho, jak je to ve skutecnosti. Stranka 'Kontakty' patri pod 'O firme' a taky to tak je. Ne, ze lezi nekde pohozene vedle sebe spojene pres nejaky cizi klic. To neni prirozene usporadani. Ta data proste nemaji tabulkovou strukturu.

Člověče, pro mě je důležité, že ze dvou ženských můžu slepit jednu se čtyřma prsama. Analogicky Vám naznačuji to, co tvrdě pomíjíte - pořád něco chcete, a vůbec, ale ani trochu se neptáme, zda to co chcete je k něčemu užitečné.

Víte, taky zapomínáte činit rozdíl mezi vnitřkem a vnějškem. Řeknu Vám to tak, na procesoru běží stroják. Fakt, je to hloupý, ale na procesoru, na kterém děláte běží stroják. Ale málokdo ho přímo vidí, dokonce ani valná většina programátorů se se strojákem nikdy nesetká. Takže třeba programátoři si chrochtají luxusem v Javě - a prostě javovský program přechroustaný těmi javacy, jvm a jitem nakonec stejně poběží ve strojáku a nikoho, opravdu nikoho to neštve.

A stejně tak Vy se v argumentaci pořád dopouštíte přehmatů, že low vrstvu dat směšujete s tím, co nad těmi daty bude dělat člověk na high vrstvě a vůbec Vám nepřijde divné, že každá vrstva chce něco jiného.

Ale to je uplne irelevantni namitka. Me jde prece o informace. Ty dokumenty si muze psat jak chce, pokud dodrzi format, tedy pokud bude vse napr. v ODF. Kdyz bude formatu vice, tak se to rozlisi do kolekci, ktere je ale mozne s dnesnimi XML nastroji stale udrzet v kontextu. Ano, bude problem, kdyz budu chtit hledat data, kdy budu predpokladat, ze jsou v tabulce a ony budou nekde odbouchane mezerami. Ale i tak mam vzdy nejakou sadu elementu, u kterych vim, ze se tam ta data muzou objevit a ze nad nimi muzu hledat.

WoW! Vám jde o informace. Jenže ty informace někde musíte schrastit. Formát ODF je Vám skoro k ničemu, neboť já jsem fakt ještě nehledal informace stylem chci text "xyz" z nadpisu provedeného fontem "Helvetica" o velikosti "20 bodů". Naprostá většina informací v ODF je formátovací. A jak znovu říkám, a jak sám píšete, data mohou být odbouchaná mezerami, tudíž je strukturálně vůbec pomocí XML dotazu nemusíte najít!!!

[xkucf03]

A fatálně chybný předpoklad je, že nasazení XML databáze Vám automaticky toto zařídí.

Přijde mi, že vy dva se tu hádáte jako by to bylo buď XML databáze nebo relační databáze. Přitom to může být relační databáze, do které se ukládají* XML dokumenty, a databáze není tak hloupá, aby s nimi pracovala jako s CLOBy, ale rozumí XML strukturám.

*) do vybraných sloupečků

[Daniel Kvasnička ml.]

A fatálně chybný předpoklad je, že nasazení XML databáze Vám automaticky toto zařídí.

Ulehci.

A znovu? Jak seženete ty spousty dokumentů pečlivě otagované? Obávám se, že tohle právě je utopie, kteoru nechcete vidět.

Co porad chcete mit otagovane? Tady konkretne jsem mluvil o CMS, tedy XML (XHTML) v nativni XML databazi dane do kontextu celeho webu. Stejne tak treba ODF ci OOXML, co na tom chcete tagovat?

A druhé věc je, že ani s XML databází, ani s relační databází se obvykle nepracuje přímo, ale přes aplikaci. V praxi to tak je - neviděl jsem sekretářku s příkazovým řádkem se spuštěným mysql -h mysql.firma.cz -u sekretarka dokumenty, jak do toho sází SQL příkazy.

No samozrejme, ja jsem mluvil pochopitelne z pozice vyvojare. A tam je produktivita prace u reseni nejakeho problemu snad dulezita, ne?

A na druhé straně, databáze, která přechroustá a rozliší tagy jde napsat i s prostředky pouhého databázového serveru. Ony relační databáze nejsou jen tupým skladištěm dat, víme?

Jiste ze vime, ale to jsme u toho, co uz jsem rikal: berlicky.

Víte, taky zapomínáte činit rozdíl mezi vnitřkem a vnějškem.

Vnitrek je ukradeny tem sekretarkam. Ale pokud ma exekutiva mozek v hlave, tak ji neni jedno, co tepe pod kapotou.

já jsem fakt ještě nehledal informace stylem chci text "xyz" z nadpisu provedeného fontem "Helvetica" o velikosti "20 bodů"

Vy mate fakt malou predstavivost

data mohou být odbouchaná mezerami, tudíž je strukturálně vůbec pomocí XML dotazu nemusíte najít!!!

Jenze to jsou dva rozdilne pripady, ktere musite rozeznat hned na zacatku, kdyz se do toho pousitite: delam aplikaci pracujici nad heterogenimi XML daty, kam muze prijit cokoliv a nebo delam aplikaci nad homogenimi XML daty napr. z nejakych sablonovych dokumentu? V prvnim pripade samozrejme musite pocitat s tim, ze ne vzdy najdete to co chcete v idealni forme. Ale porad jste a tom lepe s XML databazi, ktera za vas automaticky resi rozdil mezi daty a XML strukturou.

Jiste, je tu treba jeste DB2 pureXML uloziste, ale tam IMHO stejne nedosahnete takove dotazovaci flexibility jako u nativni XML databaze, ktera pracuje ciste s pojmy kolekci.

Chtel bych vas videt, jak byste treba postavil toto nad relacni databazi -- silne hierarchicka data s masivnim prolinkovanim mezi sebou a efektivni vyhledavani v nich. Zcvokl byste se z toho.

[xkucf03]

K tomu soubory XML vs. RSŘBD: znám z praxe obě koncepce a každá má něco do sebe, problém je ale někde jinde - když člověk potřebuje skloubit obsah z těchto dvou zdrojů (např. na web), jsou to prostě dva různé světy.

[Miloslav Ponkrác]

Souhlasím. S tímto vyváženým příspěvkem nemůžu než souhlasit.

[MJ]

Tak vězte, že pokud chci stránky pouze zobrazovat, pak je takovéto uložení stránek v relační databázi to nejlepší a přesně to co potřebuji.

Není. To, co v takovém případě potřebujete, je filesystem.

[Miloslav Ponkrác]

Filesystem je dobrá věc, ale pro malé soubory je relační databáze efektivnější úložiště. Nehledě na možnost vzdáleně se připojit k databázi a nemuset mít práva na filesystém.

[MJ]

Filesystem je dobrá věc, ale pro malé soubory je relační databáze efektivnější úložiště.

Máte nějaká konkrétní čísla, nebo alespoň důvod, proč by tomu tak mělo být? (Bavíme se o souborech velikosti webových stránek, tedy řádově alespoň jednotky KB.)

Nehledě na možnost vzdáleně se připojit k databázi a nemuset mít práva na filesystém.

Irelevantní. Způsobů, jak vzdáleně připojit k filesystemu a určovat práva tohoto připojení, je celá řada.

[Miloslav Ponkrác]

Máte nějaká konkrétní čísla, nebo alespoň důvod, proč by tomu tak mělo být? (Bavíme se o souborech velikosti webových stránek, tedy řádově alespoň jednotky KB.)

Udělejte si vlastní benchmark, budete překvapen Soubory řádově do 100KB-1MB (podle okolností) databáze obslouží rychleji, než filesystém.

Proč myslíte, že některé mailové klienty přestaly ukládat maily do fs a nasadily db?

Irelevantní. Způsobů, jak vzdáleně připojit k filesystemu a určovat práva tohoto připojení, je celá řada.

A proč mít x připojení a práv, když mi prostě stačí jednou se připojit k db a mám všechno? Navíc bez nevýhod a jednoduše?

[Kyosuke]

Že bychom jenom měli špatné nebo jen nedostatečně flexibilní filesystémy? Databáze (aspoň tedy relační databáze, do které vrznu milión mailů a předstírám, že to je jejich adresář), přeci uvnitř není o moc víc, než hodně specializovaný souborový systém.

[Miloslav Ponkrác]

S daleko rychlejším vyhledáváním, s nižší režií kolem vytváření, otevírání, čtení, zavírání souboru. S daleko efektivnějším uložením a správou místa, než má filesystém, a s daleko rychlejším přístupem oproti miliónu souborů v jednom adresáři. A to nemluvím o luxusu jako jedním SQL dotazem vrátit několik "souborů", či možnost soubory oindexovat nejen podle názvů, ale podle řady kritérií, v čemž databáze velmi rychle vyhledává.

Databáze je jednodušší útvar - ona nepotřebuje vytvářet stromy souborů zvané adresáře ve stromových strukturách a ani to přímo neumí (pokud si to nevytvoříte ve vlastní režii, a není to zrovna Oracle).

Databáze nepotřebuje spravovat řadu atributů k souboru, ani přístupových práv způsobem jako je ve filesystému.

A hlavně je databáze je odlišná v tom, že databáze vnitřně nikdy nepracuje s kouskem "souboru", pro ní je to jeden celek blob dat, a tudíž jí odpadá řešení řady problémů a operací, které řešení filesystém.

[MJ]

Pak zkuste překonat rychlost GITu něčím založeným na databázi

[MJ]

Udělejte si vlastní benchmark, budete překvapen Soubory řádově do 100KB-1MB (podle okolností) databáze obslouží rychleji, než filesystém.

Právě že jsem vlastních benchmarků udělal celou řadu, když jsem psal Sherlocka. Databáze v nich naprosto propadly.

Proč myslíte, že některé mailové klienty přestaly ukládat maily do fs a nasadily db?

Maily jsou něco dosti jiného než webové stránky, tam často potřebujete prohledávat všechny maily v mailboxu.

A proč mít x připojení a práv, když mi prostě stačí jednou se připojit k db a mám všechno? Navíc bez nevýhod a jednoduše?

Nebo naopak: Proč použít DB s nějakou další vrstvou práv, když už máte filesystem?

[xkucf03]

Maily jsou něco dosti jiného než webové stránky, tam často potřebujete prohledávat všechny maily v mailboxu.

A fulltextové prohledávání webových stránek není potřeba? Třeba tady na ABC, nebo nějaké firemní stránky?

[MJ]

Tehdy chcete prohledávat spíš hotový web, ne polotovary, ze kterých se stránky teprve sestavují.

[Miloslav Ponkrác]

Právě že jsem vlastních benchmarků udělal celou řadu, když jsem psal Sherlocka. Databáze v nich naprosto propadly.

Jste si jistý, že mluvíme o tom samém, tedy o rychlosti vracení souborových dat za a) z filesystému, za b) z kvalitní relační databáze?

Maily jsou něco dosti jiného než webové stránky, tam často potřebujete prohledávat všechny maily v mailboxu.

Myslím si, že důvod mailů v databázi nebyl jen tento, ale hlavně efektivita v případě, že byste měl velký počet malých souborů ve filesystému, pak je efektivita fs někdy i dost katastrofální. Zatímco pro databázi to není žádný problém, nebot na toto jsou přesně stavěny.

Nebo naopak: Proč použít DB s nějakou další vrstvou práv, když už máte filesystem?

Nebo naopak: Proč použít filesystém s jeho nulovými zárukami ohledně možnosti správy miliónů souborů v jednom adresáři (případně proč řešit rozhazování do x adresářů), jeho neefektivní alokací a fragmentací, když databáze je rychlejší a umožňuje další featury, které stejně na filesystému neudělám a tu databázi budu nejspíš potřeboval tak jako tak.

[Daniel Kvasnička ml.]

Zatímco pro databázi to není žádný problém, nebot na toto jsou přesně stavěny.

I nativni XML databaze pres 16.000.000 mailu v nativni XML db na "malem clusteru" (slovy autoru). V zivote jsem si nevsiml, ze by to bylo pomale.

[Kyosuke]

Teda tohle by snad dokázal oindexovat i MJův Holmes na průměrném desktopu. Při troše snahy i na notebooku. Ty maily se v reálu vejdou snad i pod deset giga. Na tohle cluster? Snad jen kvůli počtu hledajících uživatelů. Hlavně mi přijde, že nacpat okolo RFC 2822 e-mailu zobáčky a hodit ho do XML databáze je...ehm...no comment. Kdyby to byly aspoň ty strukturovaný data, ale tohle?

[xkucf03]

Tohle sice není ten případ, ale nejednou jsem si už říkal, jak by to bylo krásné, kdyby se e-maily po SMTP protokolu přenášely rovnou v XML

[Kyosuke]

Nepřemýšlel jste už někdy o návštěvě odborného lékaře? Jak už jsem psal jinde, to, že někteří lidé touží po všelijakých věcech, ještě neznamená, že toto nadšení budou sdílet všichni.

[Ondrej 'SanTiago' Zajicek]

Ackoliv nejsem priznivcem XML, ve srovnani s MIME a UTF-7 na me XML pusobi jako mensi zlo.

[Kyosuke]

Tak snad není sporu o tom, že nějaké vyčištění by to sneslo. Ale stále ještě si pokouším představit, co by udělal s celosvětovou sítí přechod na XML obálky. Jak říkám, viděl jsem Expat v akci v porovnání se schemovským readerem a žádná sláva. BTW, jak bys řešil to kódování v XML, když osmý bit IIRC pořád ještě snad není bezpečný a v XML je UTF-8 default?

[Ondrej 'SanTiago' Zajicek]

Ma predstava 'emailu v XML' zahrnuje i 8-bitove cisty prenosovy mechanismus. Bez toho ta predstava neni ani trochu lakava.

[xkucf03]

Ale stále ještě si pokouším představit, co by udělal s celosvětovou sítí přechod na XML obálky.

Vzhledem k tomu, že se XML používá u Jabberu a tam musí být zprávy doručeny okamžitě, nemusel by to být u e-mailu problém, protože tam i zpráva doručená během několika vteřin, je zpráva doručená rychle (zatímco u IM by takové zdržení bylo nepřijatelné).

Otázka je, kam až by to mělo zajít:

1. V XML budou jen vnitřky zpráv, které čte e-mailový klient. SMTP servery se žádným XML pracovat nebudou a žádné zpomalení nenastane (zůstanou vlastně tak, jak jsou).
2. V XML bude i informace, kam se zpráva doručuje (RCPT TO). SMTP server tak musí parsovat XML.
3. Celé SMTP se přepíše a bude komletně založené na XML. Bude tudíž velmi podobné XMPP (Jabberu).

[MJ]

Ono se UTF-7 někde běžně používá? Řekl bych, že spíš UTF-8 buďto přes 8-bitově čistou přenosovou cestu, nebo zabalené do base64.

[Ondrej 'SanTiago' Zajicek]

Mas pravdu, spletl jsem si to s MIME Encoded words.

[xkucf03]

Nepřemýšlel jste už někdy o návštěvě odborného lékaře?

Diagnóza: těžká závislost na Javě*, posedlost OOP, zvýšené XML, SQL pozitivní. Zvýšené hodnoty slintání u: KDE, Linux, Jabber, UTF-8. Oblíbené oblečení: LaTeX. Pokročilá paranoia (léčitelné pomocí SSL, GPG, SSH). Známé fóbie: MS Windows, .NET, uzavřený software, assembler, vi, Visual Basic.

*) jazyk i nápoj

[Daniel Kvasnička ml.]

Kdyby to byly aspoň ty strukturovaný data, ale tohle?

Thread v mailing listu je pro vas malo hierarchicky? Nebo si fakt myslite, ze to tam ukladaji jako pouhy seznam mailu a odkazuji se mezi tim nejakymi klici? Jo to v klasicke relacni databazi, tam by to tak museli delat.

IMHO je to dobra ukazka. A i kdyby "jen deset giga" -- dneska neni malo aplikaci, ktere se pohybuji "jen" v takovych cislech. Ne vse musi byt hned staveno na petabajty dat. Dneska taky koupite i jine auto, nez tahac IMHO kdyz se podari odbourat problem nutnosti stavet cely XML strom do pameti (STX?), tak se extremnich objemu dat nebude muset bat ani XML.

[Ondrej 'SanTiago' Zajicek]

Thread v mailing listu je pro vas malo hierarchicky?

Ukladat thread mailu jako hierarchii zanorenych dokumentu je IMHO uplne zcestne. Threadova struktura je jen jedna z mnoha moznych struktur vystavenych nad maily, nema smysl do ni formovat i primarni data.

[MJ]

Stejně jako je ale úplně stestné ukládat je jako tabulku v relační DB

[Daniel Kvasnička ml.]

Zcestne? Znate snad jiny zpusob ulozeni, ktery v tomto pripade odpovida skutecnosti vice nez hierarchicke zanoreni a la XML? Muzeme se bavit o alternativne k XML, ale v principu nic blizsiho skutecnosti neni.

[MJ]

Scestné. Struktura threadů především není striktní stromová hierarchie, je to obecný acyklický graf.

[Filip Jirsák]

To jako že jeden e-mail může být odpovědí zároveň na více e-mailů? To by mne zajímalo, jak se to vyjádří v hlavičkách takové zprávy. A taky bych rád viděl nějakého e-mailového klienta, kterého používají víc jak dva lidi, který něco takového umí vyrobit.

[MJ]

To jako že jeden e-mail může být odpovědí zároveň na více e-mailů?

Ano, přesně tak.

To by mne zajímalo, jak se to vyjádří v hlavičkách takové zprávy.

References: seznam Message-ID všech nadřazených mailů

A taky bych rád viděl nějakého e-mailového klienta, kterého používají víc jak dva lidi, který něco takového umí vyrobit.

Řekl bych, že je to docela běžné chování, ale chcete-li konkrétní příklad, tak třeba Mutt.

Ale to není úplně celý příběh. Ve skutečnosti se v References uvádí ID-čka všech nadřazených mailů – jinými slovy ID mailů, na které odpovídám, ke kterým se přidají References ze všech těchto mailů. Díky tomu pak lze rekonstruovat smysluplnou strukturu, i když Vám část threadu chybí.

[Filip Jirsák]

No jo, měl jsem si to RFC nejdřív otevřít. Vždycky jsem měl za to, že se odkazuje vždy jen na rodiče. Ale obecný acyklický graf tedy vznikne jedině v případě, kdy se nějaký e-mail ztratí a není jasné, kdo je rodič a kdo prarodič. Ale že bych vzal dva či více e-mailů a k nim poslal najednou jednu odpověď, to se snad nepoužívá – i kdyby to Mutt uměl

[MJ]

Používá se to docela běžně, zkuste nahlédnout třeba do archivu LKML.

[Daniel Kvasnička ml.]

Otazka je, jak casto se takova vec pouziva, jak psal Filip Jirsak. A pokud tedy predpokladame, ze se pouziva naprosto minimalne, pak mi pripada, ze je porad lepsi zvolit stromovou strukturu s tim, ze u zprav s "vice rodici" se ty informace dodatecne pridaji.

[MJ]

Ono to je naopak: teprve z toho grafu (často nekompletního) věštíte stromovou strukturu. Docela poučné je přečíst si, jak to dělá Mutt.

[Daniel Kvasnička ml.]

Orientovany acyklicky, ne?

[xkucf03]

Nacpat celou e-mailovou konferenci (nebo její vlákno) do jednoho XML dokumentu mi nepřijde moc vhodné (i když by to samozřejmě šlo). Ideální by byla asi hierarchická databáze. Ale použitelná je i relační databáze* nebo relační DB s podporou práce se stromovými strukturami (Oracle...)

*) které jsou mnohem používanější, odladěnější, vyspělejší.

[xkucf03]

jako hierarchii zanorenych dokumentu

Tenhle způsob vnořování by ale byl vhodný např. když člověk přeposílá někomu kopii mailu (Fwd) vnořil by se původní mail, včetně všech hlaviček. Nebo třeba odpovědi - u nich se dnes původní text často vloží jako obyčejný text, akorát má předřazené > před sebou.

Neříkám, že by maily v XML posunuly komunikaci nějak skokově dál, ale pokrok by to byl a ve výsledku i ušetření práce. Ale na druhou stranu to dneska jakž takž funguje - můžu posílat maily s češtinou (UTF-8), HTML formátováním, přílohami, takže nic zásadního ke štěstí nechybí

[Filip Jirsák]

můžu posílat maily s … HTML formátováním, přílohami, takže nic zásadního ke štěstí nechybí

Mně by tedy udělalo radost, kdyby tohle spousta lidí dělat nemohla…

[xkucf03]

To už jsme tu ale taky probírali: když někdo do mailu naprasí milion tagů FONT, obrázky a HTML kvalitou na úrovni Wordu a megabajtové pozadí ve formátu BMP, tak se mi to taky nelíbí. Ale když se HTML formátované maily používají s rozumem, tak to považuji za přínosné: tučné písmo, skloněné písmo, odrážky, v extrémním případě nějaká barva.

[MJ]

Nebo třeba odpovědi - u nich se dnes původní text často vloží jako obyčejný text, akorát má předřazené > před sebou.

To je naopak věc velice pozitivní, protože každý aspoň trochu slušný člověk takto cituje pouze tu část původní zprávy, na kterou odpovídá.

Neříkám, že by maily v XML posunuly komunikaci nějak skokově dál, ale pokrok by to byl a ve výsledku i ušetření práce.

Zajímavý nápad … ale jak byste řešil třeba binární přílohy?

[xkucf03]

Zajímavý nápad … ale jak byste řešil třeba binární přílohy?

Ty se dají převést na base64 a zabalit do značek < ! [CDATA[ ... ]] > Optimální to není, ale horší než dnešní stav taky ne.

[Filip Jirsák]

Nebo to můžete risknout, base64 kódování vynechat a doufat, že v datech nebude sekvence ]]>. Že tuhle sekvenci nejde v CDATA nějak „escapeovat“, to není zrovna šťastně vymyšlené…

[MJ]

Famous last words …

[Filip Jirsák]

Přesně tak První „opravdový“ uživatel, který by takový program zkoušel, by zcela jistě do testovacího e-mailu z důvodu, který by později nebyl sám schopen vysvětlit, přidal jako přílohu textový soubor s jednou větou a pěti náhodnými znaky, z nichž tři by tvořily sekvenci ]]>.

[xkucf03]

Když ale výsledný XML soubor zagzipujeme, dá se i s tím base64 přežít:

-rw-r--r-- 1 xxx xxx 62097 2008-07-05 16:09 soubor.png
-rw-r--r-- 1 xxx xxx 83886 2008-07-05 21:21 soubor.png.base64
-rw-r--r-- 1 xxx xxx 60569 2008-07-05 21:20 soubor.png.base64.gz
-rw-r--r-- 1 xxx xxx 57005 2008-07-05 21:22 soubor.png.gz

V podstatě není potřeba měnit XML, ale stačilo by najít úspornější náhradu za base64.

[MJ]

Ano, přežít se s tím dá, ale nejdříve data nesmyslně nafouknout a potom se to snažit zachraňovat kompresí je prostě bastl, takový trabant s proudovými motory.

Pozornosti ostatně doporučuji hlavně ten poslední řádek

[xkucf03]

Ten jsem tam původně ani nechtěl dávat, ale pak jsem si řekl, že budu korektní a trochu sebekritický Nicméně jak se to liší od dnešních mailů, kde se base64 pro binární přílohy taky použije?

Tady jsou výsledky s cca 1MB souborem (binární, už zazipovaný):

octave> soubor=1803425
soubor =  1803425

octave> base=2436208
base =  2436208
octave> gz=1850726
gz =  1850726
octave> rar=1886374
rar =  1886374
octave> p7z=1869197
p7z =  1869197

octave> base/soubor
ans =  1.3509
octave> rar/soubor
ans =  1.0460
octave> gz/soubor
ans =  1.0262
octave> p7z/soubor
ans =  1.0365

Po převodu na base64 a gzipování zabírá soubor jen o 2,62% více

(gzip s volbou --best, ostatní ve výchozím nastavení)

[thingie]

Jaký přibližně má smysl převádět data do Base64 a pak je zkomprimovat?

[MJ]

Nicméně jak se to liší od dnešních mailů, kde se base64 pro binární přílohy taky použije?

V tom, že u dnešních mailů se použít nemusí

[xkucf03]

V tom, že u dnešních mailů se použít nemusí

To zní hezky. Ale když jsem projížděl svoji schránku, všechny maily s binární přílohou ji měly v base64. Takže je otázka, jak moc se to používá.

[MJ]

Ehm, řekl bych, že je to horší než dnešní stav minimálně o těch 33%, která jste zbůhdarma přidal k velikosti dat.

[xkucf03]

Když dneska pošlu mail, tak je taky větší než velikost binární přílohy - base64 se používá stejně.

[MJ]

Nemusí, pokud všechny MTA po cestě podporují ESMTP 8BITMIME, což je dneska velmi běžné.

[JS]

Jo jo, Holmes rulez. Kolega ho nasadil v praci na dokumentaci, a nemuzeme si ho vynachvalit.

[MJ]

Mimochodem, kdybyste měli jakékoliv nápady, co na Holmesovi zlepšit, dejte vědět. Chceme se přes léto pustit do nové verze.

[Kyosuke]

Já už jsem si tak nějak soukromě zadal projekt filtru pro ODF a OOXML, ale ještě musím nastudovat, co Holmes od vstupních filtrů čeká - ale nemuselo by to (snad ) být tak složité. Mohl by to vlastně dokonce obsloužit jeden prográmek, kterému se zadá jedno nebo druhé schéma toho, co je důležité. V rámci studování Holmese jsem si jako druhý úkol zadal napsání dokumentace, což je slovo, kterému přisuzuji jiný význam, než jaký ve mně evokuje obsah adresáře doc/ . No a pak je tu třetí nápad, nahradit si s tím Beagle a Recoll na desktopu. Ale to bude na dlouho. Hezky všechno popořadě. Ale něco bych mohl mít ještě letos.

[MJ]

Napsat filtr není nijak těžké, byť u ODF to bude trochu zkomplikované tím, že je nejdříve potřeba rozbalit ZIP. (Ovšem parser na ZIP už má Jakub Horák prakticky hotový, jen ho vyleštit a napojit.) Rád pomohu.

Mimochodem, v libucw se také nedávno objevil moc pěkný XML parser, pravděpodobně jak rychlejší, tak příjemnější na používání než ty, které jsme zatím potkali. Ne že bychom měli XML rádi, ale přeci jen je občas potřeba se s ním poprat a když už, tak aspoň příjemným parserem

Dokumentaci by to určitě chtělo, beru všemi deseti.

Nahradit něčím postaveným na Holmesovi Beagla by rovněž stálo za to (mimochodem, už delší dobu další z mých vypsaných ročníkových projektů ), kdyby ses do toho chtěl pustit, rádi poradíme.

[Kyosuke]

Bezva. Teď ještě musím vyměnit čip v budíku, abych měl den s aspoň čtyřiceti hodinami. V podstatě jsem osobně zainteresován na všech těchhle věcech, takže motivace je. (Obsah nastřádaných...ehm...textových dat , ve kterém bych se rád vyznal, se momentálně blíží deseti mLoC. )

XML parser bych pochopil (taky bych ocenil něco duševně zdravého, ale budu fakt zvědavý, jestli projde všemi testy), ale pro ZIP není žádná rozumná knihovna?

[MJ]

Inu, nenašli jsme takovou, která by byla dostatečně robustní. Na dekompresi samotnou samozřejmě používáme zlib, zbytek je v podstatě parsování hlaviček, a to není nijak těžké.

[JS]

Mimochodem, kdybyste měli jakékoliv nápady, co na Holmesovi zlepšit, dejte vědět. Chceme se přes léto pustit do nové verze.

No, myslim, ze nam to vyhovuje, az na tu rychlost, na te byste meli teda zapracovat... Ne vazne, je to vynikajici, o rad rychlejsi nez vsechno ostatni, co kolega zkousel . Navic si to narozdil od jinych vyhledavacu dokaze poradit i se znaky @#$&% v identifikatorech, ktere jsou bezne v mainframove dokumentaci (na kterou to pouzivame).

[Kyosuke]

A že na dokumentaci k MVS/zOS je zapotřebí fakt výkonný vyhledávač.

[JS]

Ja jsem nikde netvrdil, ze jde o nejake super-duper-enterprise nasazeni. Je to uzitecna vec. To s tou rychlosti byl vtip, ja vim uz davno, ze je to dabelsky rychle, ostatne od neceho na cem se podepsal Martin Mares bych ani nic jineho necekal. Kolega zkousel jeste myslim Coveo a Beagle, a oba ty dokumenty indexovaly pul dne, zatimco Holmes to zvlada za pul hodiny (to rikam po pameti, takze muzu byt dost vedle). Nehlede na to, ze oba mely problemy se specialnimi znaky.

[Kyosuke]

Já to myslel celkem vážně, někde se mi válí celé CDčko dokumentace jen ke starému System/370, nechci domýšlet, kolik dokumentace má System Z dneska. A že Beagle je mrcha líná, to vím už dávno.

[JS]

Dokumentace jen k z/OS ma asi 2 gigabajty (PDF), pak jsou samozrejme jeste IBM produkty (jako DB2, CICS apod.) a z/VM, ty budou mit neco okolo 5GB. Ja bych odhadem rekl, ze muzeme mit zaindexovano neco kolem 15-20GB dokumentace, ale to je jen od oka.

[MJ]

Však na rychlosti jsme od doby vydání předchozí verze také pořádně zapracovali

Například umíme do vyhodnocovaní jednoho dotazu zapojit více počítačů najednou, nebo samozřejmě všechny procesory jednoho počítače.

[JS]

Vlastne jo, je jedna oblast, na ktere byste mohli zapracovat - propaganda. Z me zkusenosti skoro nikdo Holmese nezna. Mozna to tak neni a mozna vam to nevadi (me to mrzi akorat z toho duvodu, ze si myslim, ze je to skvely kus software a vetsi podil by si zaslouzil). Nekdo tu zminil ty rocnikove prace, a dostat to treba jako desktop vyhledavac do nejake bezne distribuce by bylo idealni. Ale nevim, jak to mate s tou komercni verzi, jestli by to nebyl trochu problem.

[MJ]

S komerční verzí by určitě problém nebyl, ta obvykle funguje tím způsobem, že když si někdo objedná nějaký modul na zakázku, zdrží se tento modul nějaký čas v komerční verzi, než probublá do té volně šiřitelné. Letos v létě toho ostatně probublá docela dost, můžete se těšit například na indexování tagů z MP3 a Oggů a různé pěkné paralelizační featurky.

[MJ]

Inu, jestli chcete pořád dokola kolovrátkovat, že DB je rychlejší, aniž byste to podložil benchmarkem nebo nějakým solidním teoretickým důvodem, pak mi asi nezbude, než Vás nechat hyenám.

Jen dvě poznámky si neodpustím: (1) Databáze obvykle nemůže být rychlejší než FS už proto, že ona sama bydlí v souboru na onom FS. (2) Databáze obvykle na položky velikosti od jednotek do stovek KB (typické maily) nejsou optimalizovány – optimum leží výrazně níže, spíš na desítkách až stovkách bajtů.

[Kyosuke]

Striktně vzato nemusí bydlet v souboru. Třeba můj oblíbený Firebird v nové verzi 2.1 umí i raw oddíly, i když pravda, jediná záruka, kterou tím získá, je souvislé pořadí bloků. Ovšem taky souhlasím s tím, že jestli pro normální náhodný přístup k pársetkilovým souborům je FS výrazně pomalejší, je spíš něco špatně se souborovým systémem.

[MJ]

Přiklonil bych se spíš k názoru, že pokud je to na nějakém běžném Linuxovém FS, tak je něco špatně s benchmarkem

[Heron]

Jen dvě poznámky si neodpustím: (1) Databáze obvykle nemůže být rychlejší než FS už proto, že ona sama bydlí v souboru na onom FS. (2) Databáze obvykle na položky velikosti od jednotek do stovek KB (typické maily) nejsou optimalizovány – optimum leží výrazně níže, spíš na desítkách až stovkách bajtů.

A toto máš ověřené nějakým benchmarkem, nebo je to přání? Protože podle (jednoho) benchmarku začne být FS rychlejší až pro záznamy o velikost stovek kB a větší.

[MJ]

(1) je prostý fakt, ten netřeba ověřovat benchmarkem

(2) je docela dobře vidět z toho, jak databáze hospodaří s bloky a volným místem.

Sem s tím benchmarkem.

[Heron]

ftp://ftp.research.microsoft.com/pub/tr/TR-2006-45.pdf

Pro MySQL a ext3 bmark chystám.

[MJ]

Na kombinaci Windows + NTFS mne to moc nepřekvapuje, nevíte o nějakém Unixovém benchmarku? Nejlépe ext2 nebo XFS.

[Heron]

Nevím, počkej si týden, snad si najdu čas.

[xkucf03]

Ad 1: vůbec to není tak jednoduché - databáze sice většinou ukládá data do souboru*, ale pak záleží na vnitřní struktuře toho souboru, stejně jako u FS záleží na vnitřní struktuře diskového oddílu. Při práci se spoustou malých souborů se hodně FS dostává do úzkých, zatímco databáze běžně zvládají tabulky s řádově vyššími počty řádků. Rovněž taky prohledat indexovanou DB trvá často méně než prohledat souborový systém (byť hledáme jen podle názvu souboru).

*) nebo může ukládat přímo na oddíl disku, ale to většinou přinese víc škody než užitku. Rychlost práce s jedním velkým (nefragmentovaným) souborem se řádově neliší od práce s oddílem disku.

[Filip Jirsák]

Rovněž taky prohledat indexovanou DB trvá často méně než prohledat souborový systém (byť hledáme jen podle názvu souboru).

To už tak bývá, že hledání podle indexu bývá výrazně rychlejší než fullscan. Některé FS snad mají názvy souborů zaindexované, ale myslím, že to ještě není standardní vlastnost FS.

[MJ]

Indexování názvů souborů není nic exotického, má je i úplně obyčejná ext3.

[Filip Jirsák]

Ve výchozím stavu je to ale vypnuté, ne? Alespoň můj bootovací ext3 oddíl dir_index nastaveno nemá.

[Kyosuke]

Chyba. Ext3 AFAIK snad už roky indexuje názvy souborů v adresáři de facto pomocí téže přístupové metody, kterou databáze používají pro indexy.

[MJ]

Téže ne, dělá to o něco chytřeji. Využívá toho, že není potřeba uspořádání klíčů, takže kombinuje hashování s B-stromy.

[MJ]

Ovšem úplně stejně jako můžete indexovat data uložená v tabulce, můžete to dělat s daty v souborech. Tu žádný rozdíl není.

[xkucf03]

Můžeme, ale otázka je jaký FS to dělá a jakých výsledků při tom dosahuje. Třeba takové obyčejné ls /etc/ mi přijde subjektivně pomalejší (na XFS, ext3), než si udělat SELECT podobných dat z DB (PostgreSQL, MySQL), a to nemluvím o adresářích, které mají souborů mnohem více.

[MJ]

Index často nedělá FS, ale konkrétní aplikace – šitý na míru tomu, co chce hledat.

Co se ls /etc/ týče, měl byste srovnávat se SELECTem nad tabulkou obsahující jména všech souborů na disku, aby to bylo fair.

[xkucf03]

Proč? /etc taky neobsahuje všechny soubory na disku.

[Kyosuke]

Ano, ale všechny prvky jedné relace patří (aspoň podle pana Codda) v relační databázi do jedné tabulky, že.

[MJ]

Množina dat, nad kterou operaci provádíte, je evidentně celý adresářový strom, už proto, že se v něm nejdříve musí najít, co je zač /etc, na které jste se zeptal.

[Ondrej 'SanTiago' Zajicek]

Máte nějaká konkrétní čísla, nebo alespoň důvod, proč by tomu tak mělo být?

Doufam, ze neplacam nesmysly, ale AFAIK Linux dela read-ahead pouze v ramci jednoho souboru. Takze pokud budes mit hromadu malych souboru, ty budou nahodou ulozeny na disku fyzicky po sobe a budes je vsechny nacitat v jinem nez sekvencnim poradi, tak se system useekuje. Pokud budou ty zaznamy v jednom velkem souboru, tak program muze predpokladat sekvencni ulozeni daneho souboru a bud podle toho usporadat pozadavky, nebo provadet vlastni read-ahead stylem 'ke kazdemu predpokladanemu seeku si nacacheuju megabajt dat z okoli'.

[MJ]

Tady spíš byla řeč o operacích nad jednotlivými soubory (typu "vytáhni mi soubor číslo XYZ"), tam stačí obyčejný read-ahead v rámci jednoho souboru. Pokud chci procházet všechny, tak samozřejmě postupné otevírání v adresářovém pořadí moc nefunguje a je potřeba se uchýlit k trochu zběsilejším technikám (pro začátek setřídit si soubory podle čísel i-nodů). Pokud sekvenční přístup převažuje, je samozřejmě lepší uložit vše do jednoho velkého souboru (to konec konců dělá i Holmes), ale určitě ne způsobem, jakým to běžně dělá databázový systém – spíš jednotlivé kusy dat skládat za sebe, neřešit evidenci volného místa (a s ní spojenou fragmentaci) a čas od času prostě vše sklepat.

[thingie]

Pokud chcete vyhledávat jenom podle jména záznamu, tak nevím v čem máte se souborovým systémem problém. To je jeho práce, kterou by měl být schopen dělat velmi rychle.

[Miloslav Ponkrác]

Viz moje odpověď výše.

[Daniel Kvasnička ml.]

Co se tyka objektovych databazi, tak pokud neberete v uvahu ORM, tak jsou mozna pomalejsi. Ale pokud chcete s relacnimi daty v aplikaci pracovat jako s objekty a pouzijete ORM, jde vykon OODBMS oproti relacnim drasticky nahoru. (pokud vim, tak db4o i NeoDatis ODB)

Ale je fakt, ze u opravdu extremnich objemu dat je problem. Ale to neni zdaleka kazdy pripad.

[xkucf03]

Relační databáze mám rád, jsou skvělé, ale taky jde o to, aby vývojář musel plýtvat většinu svého času na převody mezi objektovým a relačním světem (jasně, máme ORM). Takže se na vyspělé a výkonné XML a objektové databáze docela těším (nejlépe open source).

[Miloslav Ponkrác]

Souhlasím. Ale pokud si zahraju na vizionáře, skončí to jinak.

Podle mě se nad základem relační databáze udělají nadstavby tvářící se jako XML a OOP úložiště. Cesta bude z obou stran - relační databáze zaintegrují pomocné prvky, které to těmto nadstavbám nesmírně ulehčí (dnešní relační databáze často umějí pracovat rovnou s XML, a často obsahují OOP prvky) a nadstavby toho využijí.

Důvodem je prostě vyspělost, spolehlivost, rychlost, výkonnost a efektivita relačních databází - a to jsou atributy, které stále budou potřeba. A jakékoli přímé XML/OOP databáze s tímto nebudou moci korektně soupeřit.

Ono taková knihovna pro persistenci objektů integrovaná přímo do relační databáze třeba od Oracle/IBM/dalších, kde samotná knihovna jednak využije vnitřních mechanismů relační databáze, a jednak skryje samotnou složitost mapování mezi relačním a OOP světem IMHO bude mít vlastnosti, kterým dnešní univerzální ORM nástroje nemohou konkurovat, a kterým nebudou moci konkurovat ani skutečné OOP databáze.

[User682]

zdravim,

odpovim hodne nesrozumitelne a zamerne schvalne. Tipuju, ze autor blogu bude rozumet.

Relacni database jsou (urcite anebo ne vzdy) prezitek a brzda pokroku [rozumejte, tak ze urcite existuje nekde neco lepsiho bez vad minulosti, akorat to poradne jeste neni] . Plati dle konkretni ulohy.

Postupem doby zjistuju, ze potrebuju uplne neco jineho, co se da lepe uchopit. A to nejlepe objektove database. Proste se nechci starat o to, jak je co ulozeno a jak se na to nejakym jazykem dotazovat. Potrebuju programovat.

Me spise zajimaji dnes spise typy struktury, mapovani a na ni pouzita transformace a algoritmus (ETL). Ale o tom si tady asi v hodne pripadech nepokecame. Nebo, ze vezmu formular z kancelarskeho baliku a ruznymi rourami mi budou padat struktury a data + jejich optimalizovane podoby v ryznych vystupech.....

Ale nez budou vyspelejsi jine database, platformy a frameworky, tak to bude trvat.

Vyvoj jde ale rychle dopredu. Relacni database jsou dnes spise do ustrani a stavaji se koncovou vrstvou nez mezivrstou. Ale budou tu porad.

Co se tyce oracle a jinych databasi: nejvetsi problem pro pouziti opensource db byva casto rychlost. To jaksi opensource db pri vice datech nemaji. Za dalsi oznacim nemoznost rychle zmenit 50MB vlozenych procedur na neco jineho s optimalizaci behem par dnu, i presto, ze gramatiky jsou mocne. Ale na jednu stranu tyto firmy velmi chapu. Svym zpusobem si sve penize zaslouzi a preju jim je. A zakaznika zajimaji i jine veci. Napriklad podpora.

Pavel Kysilka

[springer]

...Proste se nechci starat o to, jak je co ulozeno a jak se na to nejakym jazykem dotazovat. Potrebuju programovat. ...

105% ACK

...nejvetsi problem pro pouziti opensource db byva casto rychlost. ...

v diskuzich na toto tema se casto uvadi google, ktery by uz byl davno bankrot, kdyby pouzil na sve aplikace oracle nebo DB2. A prave google je ta aplikace, ktera ma ty miliardy zmen v datech/den -tedy ten typicky priklad, kdy by mel mit Oracle ty vyhody.

Na rovinu, s Oracle je to jako s SAP , kdyz se neco podela, tak tomu kdo provedl to rozhodnuti pro Oracle nikdo hlavu neutrhne! To je ten pravy duvod.

[Martin Böhm]

...Proste se nechci starat o to, jak je co ulozeno a jak se na to nejakym jazykem dotazovat. Potrebuju programovat. ...

105% ACK

Musím nesouhlasit. Je docela důležité, jak je co uloženo. Algorithms + Data Structures = Programs.

[Kyosuke]

...Proste se nechci starat o to, jak je co ulozeno a jak se na to nejakym jazykem dotazovat. Potrebuju programovat. ...

105% ACK

Myslím, že ne, Time. Přinejmenším Linus Torvalds a Alan Perlis by nesouhlasili, a asi i spousta jiných. Kód se mění, datové struktury zůstávají.

[MJ]

Co se Googlu týče, to je hlavně velmi pádná ukázka toho, kdy databázi nepoužít.

[Miloslav Ponkrác]

Postupem doby zjistuju, ze potrebuju uplne neco jineho, co se da lepe uchopit. A to nejlepe objektove database. Proste se nechci starat o to, jak je co ulozeno a jak se na to nejakym jazykem dotazovat. Potrebuju programovat.

Uf! Tak to je síla! Pokud by tohle tvrdil nějaký začátečník, co se teprve chystá napsat Hello world, tak to beru. Ale programování je jedna ze svou věcí, podle toho kam se zařadíte:

1) Práce na pásu - člověk, který houby umí a dělá více, či méně mechanickou práci. Bouchá tlačítko do formuářů ve vizuálním nástroji. Lepí hotové komponenty, a sám nic není schopen napsat. Apod.. Takový člověk nepotřebuje se starat o nic, potřebuje "programovat". A ani se nesmí k niemu jinému pouštět!

2) Práce kreativní, tedy člověka, který umí. Takový ví, že programování je především práce nad daty, a žádný zkušený programátor by si nikdy nedovolil říci, že struktura dat, nad kterými pracuje ho nezajímá. Protože právě struktura dat, ať už v programu, nebo mimo program je to, co je pro vlastnosti programu i algoritmů naprosto klíčové! Může znamenat rozdíl mezi tím, zda se akce vykoná za jednu nanosekundu, nebo za 30 hodin například.

Ale nez budou vyspelejsi jine database, platformy a frameworky, tak to bude trvat.

Prakticky nebudou - relační databáze budou vždy králem - a to se vsadím o co chcete.

Pořád to vezměte jako s Unixem - natvrdo řečeno, Unix je úplně primitivní až blboučký jednoduchý systém. A právě toto umožňuje jeho vlastnosti - obrovská rychlost, spolehlivost, přehlednost a vysoká konfigurovatelnost na účel, pro který Unix potřebujete.

Stejné to bude s relačními databázemi - jsou primitivní, jednoduchoučké, ale rychlé, výkonné, spolehlivé, dávají záruky. Kdykoli o něco půjde, a kde se dá v případě chyby hodně ztratit - nikdy nenajdete nic jiného, než relační databázi.

"Vyspělejší" - ve smyslu OOP databází budou vždy mít své limity hluboko pod relačními databázemi. To totiž už OOP databáze drží obrovskou spoustu let na okraji a nejsou s to (spolu s neexistujícím standardem pro OOP databáze a neschopností OOP databází se vyrovnat s tím, jak spolupracovat s více programovacími jazyky) tyto limity překonat. Nakonec relační databáze už jsou obohacovány OOP vlastnostmi, a tím stále více zhoršují pozici a uplatnitelnost OOP databází.

O OOP databázích se mluví od té doby, co nějak existuji v IT světě - tj. přes dvacet let. Stále se o nich jenom kecá, ale skutek utek. Ony totiž OOP databáze nemají moc co V PRAXI nabídnout - a praxe tomu odpovídá. Sem tam se v jednom z miliónu případů (a to jsem ještě velký optimista) objeví případ, kdy nasazení OOP databáze je výhodné - ale problém je, že to nikomu moc nestojí za to, aby nalil miliardy dolarů do vývoje dobré OOP databáze, do prosazení nějakého standardu pro vše kolem OOP databází atd..

[Daniel Kvasnička ml.]

Ony totiž OOP databáze nemají moc co V PRAXI nabídnout - a praxe tomu odpovídá

Myslim, ze uz byste mel brzdit Kdyz se podivam kde se pouziva treba db4o, tak mi ty vase "ortely" nad OODBMS pripadnou nejak mimo realitu... Jasne, ze nemaji v dohledne dobe sanci ohrozit RDBMS, ale ta irelevance, kterou jim prisuzujete, jim zcela jiste nepatri.

[Miloslav Ponkrác]

Ok, a co udělat poměr? Poměr nasazení OOP databází v praxi a poměr nasazení relačních databází v praxi? Už by to vypadalo jinak, že? Tipuji, že bychom se pro OOP databáze dostali na nějaké milióntiny procenta.

A pak bych udělal ještě jeden poměr - a to poměr nasazení relačních databází v kritických oblastech (tedy tam, kde databáze musí dát záruky na data a na spolehlivost) a OOP databází.

[Daniel Kvasnička ml.]

Ok, a co udělat poměr? Poměr nasazení OOP databází v praxi a poměr nasazení relačních databází v praxi? Už by to vypadalo jinak, že? Tipuji, že bychom se pro OOP databáze dostali na nějaké milióntiny procenta.

Kazde nove BMW vyssich rad, ktere na ulici potkate. Plus vsechny ty dalsi pripady, ktere jsou tam popsane. Miliontina procenta?... A to je jen db4o.

A pak bych udělal ještě jeden poměr - a to poměr nasazení relačních databází v kritických oblastech (tedy tam, kde databáze musí dát záruky na data a na spolehlivost) a OOP databází.

Zaruka na data a na spolehlivost? Vojenske letadlo, rizeni rychlovlaku, plaubni kompy v autech nebo ridici systemy pro ropny prumysl jsou pro vas malo kriticke oblasti? ...jako rozsirenost je mozna mala, ale opravdu by me zajimalo, na zaklade ceho narazite na spolehlivost.

Navic pri triceti az padesatinasobnych rychlostech pristupu oproti RDBMS+ORM reseni bych rekl, ze asi chapu, proc nektere ty firmy prave pro mission critical reseni zvolily OODBMS

[Robo]

jj, lepsie by som to nenapisal; strasnou nevyhodou OOP databaz tiez je, ze su prakticky iba pre programatorov; bezny ludia (napr. analytici) potrebuju na datamining nieco jednoduche, napr. naucit sa standartny jednoduchy SQL; cestou buducnosti je skor ORDBMS; OOP databazy sa v praxy vyuzivaju len vo velmi specifickych pripadoch

[MJ]

A neměli by spíš na analýzu dat používat nějaký slušný statistický software?

[User682]

zdravim,

odpovim Vam souhrnne.

Co se tyce zpracovani dat typu prehledy/tabulky, tak budu souhlasit, ze relacni database jsou vyborne.

Moje prace je ale spise se strukturami, stromy a grafy. Psal jsem i objektovou databasi nad relacni databasi. Byly problemy obcas s rychlosti, ale predevsim s jednoduchosti uchopit to, co potrebuji ja a ne, co potrebuje database.

Byznys a optimalni narocnost prace je podle me v nejakem hybrydu mezi relacni databasi a necim dalsim,co prijde. A ten hybrid tu stale neni.

Soucasne pozadavky na struktury jsou dnes podstatne jine nez pred lety. Zasadni vec pro me je moznost zmeny a odolnost systemy proti zmene. A zde prave relacni database jsou velkou brzdou. A nemyslim si, ze reseni je pouze v frameworcich a vyvojovych nastrojich. Zde se prave vytraci nejaka jednoduchost.

Co se tyce dat, tak me uz dneska moc nezajima jake jsou. Struktury(a to i rozpoznane) jsou pro me vstupni vstupni data. Da se rici, ze cloveka jiz spise zajimaji toky dat nez, co kde tece. Manipulace s daty(zobrazeni, ukladani, validace,...) se ridi urcitymi vetsinou pevnymi pravidly a nema smysl je v alespon polovine do nekonecna opakovat a implementovat.

Hodne velky problem je v rel. databasich prechazet od konkretniho modelu k metamodelu a zpet.

Problemy relacnich databasi jsou pro me z moji praxe zname. A spise je to otazka jejich (mozna castecne) nahrady. Tohle je spise na sezeni u piva (linuxovy patek za mesic). Ale oba budeme mit pravdu. Popsali bychom tu hodne kB textu a asi si tu moc nevysvetlime. Navic muj cas je v soucasne dobe drahy. Ale u piva rad popovidam.

1,2 jsou spravne. bod 3 (odpoved) jste nenapsal a je o neco vice spravny. Jinak dobry odhad, prognozy a zmapovani situace.

Pavel Kysilka

[Kyosuke]

"Vyspělejší" - ve smyslu OOP databází budou vždy mít své limity hluboko pod relačními databázemi. To totiž už OOP databáze drží obrovskou spoustu let na okraji a nejsou s to (spolu s neexistujícím standardem pro OOP databáze a neschopností OOP databází se vyrovnat s tím, jak spolupracovat s více programovacími jazyky) tyto limity překonat. Nakonec relační databáze už jsou obohacovány OOP vlastnostmi, a tím stále více zhoršují pozici a uplatnitelnost OOP databází.

Ano. Spolupráce s více programovacími jazyky je skutečně něco, co by se dalo označit za výsostné vody relačních databází. Ona je v prcní řadě tabulka natolik "pitomá" datová struktura, že jí rozumí každý jazyk. A naopak je těžké standardizovat programovací jazyk pro objektové databáze, když jejich hlavním smyslem je maximálně přiblížit model dat modelu programovacího jazyka a "prostě programovat" a zkuste něco takového, když ti oškliví návrháři programovacích jazyků udělali každý jazyk úplně jiný.

O OOP databázích se mluví od té doby, co nějak existuji v IT světě - tj. přes dvacet let. Stále se o nich jenom kecá, ale skutek utek. Ony totiž OOP databáze nemají moc co V PRAXI nabídnout - a praxe tomu odpovídá. Sem tam se v jednom z miliónu případů (a to jsem ještě velký optimista) objeví případ, kdy nasazení OOP databáze je výhodné - ale problém je, že to nikomu moc nestojí za to, aby nalil miliardy dolarů do vývoje dobré OOP databáze, do prosazení nějakého standardu pro vše kolem OOP databází atd..

Tady se vykašlete na standard, bude Vám k ničemu, radši se snažte v případě nasazení něčeho takového vytežit co nejvíc z výhod a nebrečet nad tím, že se do toho nepřipojíte z džavy. Pokud OODBMS potřebujete, dobré implementace existují, někdy dokonce velmi dobré implementace, pokud používáte ten správný jazyk (a pokud ho nepoužíváte, stejně nechápu, proč chcete programovat efektivně v jednom kusu aplikace a v jiném už ne ). (Tento přípěvek může obsahovat stopové množství sarkasmu a flamebaitu. Nevhodné pro děti do třiceti let. )

[daeltar]

Tady se mi líbí zajímavý pokus o implementaci programovacího jazyka(ruby) + k tomu přihodit objektovou databázi - koukněte na maglev - http://ruby.gemstone.com/

[Stevko]

Ale programování je jedna ze svou věcí, podle toho kam se zařadíte

Ja by som pridal ešte tretiu vec: programovanie je zlo, ktorého sa treba čo najrýchlejšie zbaviť (alebo ho aspoň presunúť na niekoho iného).

[JS]

To ale nic nemeni na tom, ze relacni model je jeden z nejuniverzalnejsich popisu datovych struktur, ktery mame (s dobre definovanym dotazovacim jazykem). Podle me relacni databaze budou casem nahrazeny vecmi jako: http://datadraw.sourceforge.net/

Ale relacni model zustane. Jiste, ma sve nevyhody, jak psal vyse Martin (MJ), ale mam pochybnosti, ze se mu objektove databaze mohou rovnat. Nemaji zdaleka tak dobre definovanou semantiku ani matematickou teorii jako relacni model.

Vubec podle me je objektove-orientovane programovani je krok zpatky - misto centralizovane definice datove struktury (ktera pak umozni uvazovat nad korektni implementaci) se ta struktura rozhodi do rady provazanych malych objektu.

[MJ]

Relační DB jsou sice velice dobře teoreticky popsané, ale současně je také z této teorie bohužel známo, že je to model dosti slabý. Takže určitě potřebujeme něco lepšího, jen je otázka, co by to mělo být.

[JS]

Ten problem velmi rad prenecham genium, jako jsi ty. Me v soucasnosti spis trapi problem, jak nechat volbu datovych struktur na kompilatoru, abychom i my normalni smrtelnici mohli efektivne vyuzivat vsechny pokrocile datove struktury, ktere soucasna comp-sci nabizi. Urcite napady v tomto smeru mam, nicmene rad si poslechnu tvuj nazor.

[MJ]

Tohle se dělá automaticky opravdu těžko, ale pár možností, jak se k optimu přiblížit, přeci jen je. V zásadě by stačilo vzít nějaký hodně abstraktní programovací jazyk (třeba Haskell), v něm si napsat primitivní datové struktury a měřit, jak konkrétní program tyto struktury používá. Podle naměřeného chování pak automaticky zvolit chytrou strukturu šitou na míru těm operacím, na kterých záleží.

[JS]

Presne tak to chci delat. Akorat ze chci pouzit relacni model a vyuzit celou tu znalost o tomto problemu, ktera se uz resi pri optimalizaci databazi. Takze, mit neco mocnejsiho nez je relacni model by mi velmi pomohlo.

[Kyosuke]

hodně abstraktní programovací jazyk (třeba Haskell)

Huáá, tak už rozumím prvním dvěma písmenkům - HAskell = Hodně Abstrakní Skell - teď ještě vyluštit ten zbytek.

[thingie]

Strašně Khůl, Eště Lepší Lispu.

[Miloslav Ponkrác]

Potřebujeme něco lepšího Jen nevíme, co to je, a než na to za 300 let přijdeme, bude nejlepší relační databáze

[Miloslav Ponkrác]

Přesně o tom to je. U OOP databází je to každý pes jiná ves. Není standardizován jazyk pro dotazy nad OOP databází. Není standardizován způsob mapování objektů v OOP databázi nad libovolným programovacím jazykem. A spousta dalších věcí. Pak není divu, že se o nich hlavně mluví.

Já myslím, že hlavní nevýhoda OOP databází je, že se u nich neuvažuje o rychlosti a efektivitě. A na tom to nakonec prohrávají, protože jakmile jde o výkon (nebo je předpoklad, že v budoucnosti půjde o výkon, či obrovská data), tak nikdo, naprosto nikdo se neodváží nasadit nic jiného, než relační databázi.

Podle mě by se mělo věnovat výzkumu nalezení rychlých algoritmů a principů pro práci s OOP databázemi, a vhodných dotazovacích jazyků a rozhraní. Protože dokud tohle nebude, budou OOP databáze jen na okraji pro velká nasazení.

[MJ]

Já myslím, že hlavní nevýhoda OOP databází je, že se u nich neuvažuje o rychlosti a efektivitě. A na tom to nakonec prohrávají, protože jakmile jde o výkon (nebo je předpoklad, že v budoucnosti půjde o výkon, či obrovská data), tak nikdo, naprosto nikdo se neodváží nasadit nic jiného, než relační databázi.

Když jde o obrovská data, ve kterých je potřeba hledat efektivně, málokdo se odváží použít i tu relační databázi. Obvykle sáhne po něčem, co je ušité na míru konkrétním datům a potřebným dotazům.

[Kyosuke]

Jenom malá korekce...doktor Codd opravdu nepracoval v Oracle.

[springer]

ale my ted urcite nechceme vest diskuzi o tom, co je dulezitejsi - vypracovat teoreticke zaklady nebo na tech zakladech neco uvest do praxe. Venujme se radeji te skutecne problematice, jak ji myslim skutecne trefne popsal pan Kysilka -> my chceme programovat.

[JS]

Pointa byla, ze nejenze relacni model vymyslel pan Codd, ale prvni ho implementovala IBM ve sve DB2 (pokud vim, tak "DB1" byla IMS). Takze Oracle nemel pri zrodu relacniho modelu zadnou roli.

[Kyosuke]

Nene, DB/2 přišla až mnohem později. A IMS určitě nebyl "DB1". IBM těch systémů přeci i mezi tím měla mnohem víc. (Ale myslel sle, že Dad jako stařec nad hrobem si to bude ještě pamatovat. )

[JS]

Aha, ja jsem mel pocit, ze je Wikipedia spatne, ale to je sila autority. :) (trochu to plyne z IBM DB2) S tim IMS nevim. Ale vzdycky jsem mel podezreni, ze DB2 ma 2 jako nastupce IMS, z marketingovych duvodu, protoze IMS byla dost uspesna. Rad bych si nekde precetl, jak to vlastne bylo. Nasel jsem tenhle odkaz, a tam pisou, ze prototypem DB2 byl System R. Je to co mate na mysli?

[xkucf03]

tak se z jednoho CD stava 'sluzba'na pocitacich zakazniku. Je to nepekna praxe, ktera odepira svobodu rikaji ti jedni

Říkat můžou, ale používat Oracle a platit roční licence je nikdo nenutí - buď ber nebo nech ležet. Když to zákazníci nebudou chtít, přejdou ke konkurenci, open sourcu nebo jiným komerčním SW, které si lze koupit (respt. licencovat na neomezenou dobu).

ten nesmysl - relacni databaze - ktere nas dnes a denne provazeji a zdrzuji od prace.

< rýpnutí > Možná je jen neumíš používat, mně relační databáze šetří spoustu práce. < / rýpnutí>

At uz jsou nazory jakekoliv, oteviral by se zde prostor pro svobodne software. Oracle a DB2 jsou produkty, ktere potrebuje tak akorat 5% vsech zakazniku, zbytek by vysatacil z opensource produkty.

1. Korupce
2. Říká se takový vtip: Proč Oracle? Protože ještě nikdo nebyl vyhozen za to, že doporučil kopit Oracle.

[springer]

...buď ber nebo nech ležet....

kdyby bylo v zivote vsechno tak jednoduche. V tom sporu jde o zasadni problematiku, kterou vyjadril jeden diskutujici na zahranicnim portalu takto:

'cekam na ten den, kdy mi pekar na rohu proda vylucni licenci na konzumaci housky'

My lide mame zakodovano, ze kdyz neco ziskame (napr. koupi), tak s tim muzeme dale nakladat jak uzname za vhodne. S tim, ze se objevuje stale vice produktu, ktere jsou infikovany jakymsi virem autorskeho prava je nam toto 'rozumne' pravo odebirano a to nas v dalsi cinosti omezuje. Predstavte si, ze u te smlouvy s pekarem stoji, ze tu housku muzete snist pouze mezi 11 a 12 hodinou a nesmite ji nikomu dalsimu prodat. Pekarum by se neco takoveho urcite libilo. Rekli by .... 'buď ber nebo nech ležet' ...

[Filip Jirsák]

Ale pekař vám přece prodává housku, a vy si s ní můžete dělat co chcete. U softwaru je to jiné – vy si platíte nějakou funkcionalitu, a nemusíte se starat o to, jak to autor software zařídí. Kdyby se prodával software jako housky, nasype vám firma na CD hromadu nul a jedniček, a dělejte si s tím, co chcete. Že to nemá žádný vám známý spustitelný formát? To je váš problém, chtěl jste program, tady ho máte. Přesněji řečeno, kdyby se software prodával jako housky, dostával byste pouze výstupy toho software. Pekař, který peče housku, zná nějaký postup, a vy si koupíte teprve produkt tohoto postupu – hotovou housku. Kdybyste od něj chtěl recept, určitě bude mít jiné podmínky, než když vám prodává už hotovou housku. A když si kupujete software, kupujete si právě ten postup, recept, s tím, že výsledné produkty už si budete vyrábět sám.

[Luk]

Predstavte si, ze u te smlouvy s pekarem stoji, ze tu housku muzete snist pouze mezi 11 a 12 hodinou a nesmite ji nikomu dalsimu prodat. Pekarum by se neco takoveho urcite libilo. Rekli by .... 'buď ber nebo nech ležet' ...

Oni by na to brzy dojeli. Protože by se brzy našel jiný pekař, který by takové omezení neměl a přetáhl by jim všechny zákazníky.

[xkucf03]

'cekam na ten den, kdy mi pekar na rohu proda vylucni licenci na konzumaci housky'

Od toho je tu trh - v takovém případě půjdeš k pekaři naproti, protože ten ti housku prostě prodá*.

S tim, ze se objevuje stale vice produktu, ktere jsou infikovany jakymsi virem autorskeho prava je nam toto 'rozumne' pravo odebirano a to nas v dalsi cinosti omezuje

Když si koupíš open source program, platíš např. za podporu na jeden rok. Vyvineš-li software, kdo by měl rozhodovat, za jakých podmínek ho mohou uživatelé používat? Zda bude open source, nebo zdrojáky dostane jen někdo? Zda bude placený nebo ne? Zda k němu bude poskytována technická podpora? Zda bude mít záruku, nebo hude poskytován tak, jak je? Měl by o tom rozhodovat autor toho softwaru, nebo nějaký centrální úřad, který řekne, co je správné a co ne?

*) není to žádný buzerant, aby na tebe kladl nesmyslné požadavky (jíst ve vybraných hodinách), které mu nic nepřinesou, on sleduje jen svůj vlastní užitek, chce vydělat, prodat housku (proto ti ji prodá a dělej si s ní, co chceš).

[springer]

v danem sporu jde o to, ze jestlize si nekdo zakoupi Oracle software a posleze ho nepotrebuje a chce ho prodat dal, tak musi poprosit Oracle, zda to smi udelat. A Oracle to budto povolit a nebo taky ne. A to je bohuzel nesvoboda, ktera se obraci proti nam vsem. Zamezuje to napr. udelat software-bundle, nemohou vzniknout firmy, ktere by napr. delaly suport pro stare verze, coz by bylo pro mnohe firmy levnejsi apod. Jestlize to co dela Oracle je OK, no tak pak se nemusime EU byrokracie co obavat.

[xkucf03]

A Oracle to budto povolit a nebo taky ne.

No a??? Chyba by byla, pokud by se Oracle při podpisu smlouvy tvářil, že ti SW prodá a ty si s ním můžeš dělat, co chceš, a po nějaké době, kdy bys chtěl ho chtěl třeba prodat dál, tak by ti to zakázal. To by mu ale ze zákona neprošlo, porušil by smlouvu.

Ale pokud už při koupi SW o omezeních víš, nic špatného na tom není. Prostě si smlouvu přečteš, zjistíš, že ti nevyhovuje (uvažuješ o pozdějším odprodeji licence) a řekněš: ne, jdu radši k PostgreSQL nebo k DB/2. A trh funguje v tom smyslu, že takhle Oracle začne přicházet o zákazníky a přehodnotí svoje podmínky. Pokud o zákazníky nezačne přicházet, znamená to, že jim tyto podmínky vyhovují* a všechno je OK.

*) resp. jsou přijatelné, protože přínosy z koupě licence jsou vyšší než náklady a nepříjemnosti spojené s restrikcemi. Kdyby ty přínosy byly nižší, zákazík by smlouvu nepodepsal.

[Dalibor Smolík]

I kdyz je treba uznat, ze takove ankety jsou mnohdy sporne - napr. jak 70% obyvatel CR si mysli, ze 'on' je tim spravnym.
WTF?

[Andrej]

Nechápu, proč není PostgreSQL už dnes rozšířenější než Oracle. Záhadou století ovšem zůstává, proč je MySQL rozšířenější než PostgreSQL. To už fakt nechápu.

Pokud jde o relační databáze, připadám si jako uživatel Windows, který umí jen klikat a nikdy nic jiného neuměl. Ve škole mě totiž učili relační databáze. Pro svou webovou stránku používám relační databázi. Můj server pro Jabber a pro mail ji používá rovněžtak. Samozřejmě vím, že existuje například Caché nebo zkrátka jiné řešení, které je (zcela objektivně) rychlejší a má spoustu dalších výhod. Ale já to řešení neznám. Nic, co znám, ho nepodporuje. Takže co s tím? Je to stejně „nesprávná“ situace jako rozšíření Windows (v oblasti closed-source) nebo MySQL (v oblasti open-source). Jenže uvedené dva případy jsem už (sám pro sebe a na svých počítačích) úspěšně vyřešil. Jen s tou databází to je složitější...

Pokud jde o otce ředitele gymnázia, musím říct, že s ním plně souhlasím. Myslím si, že volná ruka trhu existuje a funguje a když rozhodla takto, nedá se nic dělat. Žijeme ještě pořád v postkomunistické éře, což v této souvislosti znamená, že ve středních a starších věkových skupinách prakticky neexistuje vzdělání v oblasti výpočetní techniky. Momentálně vidíme enormní propast mezi dostupností počítačů a znalostmi veřejnosti v oboru IT. Jsem přesvědčen, že se tento rozdíl bude postupně zmenšovat a jednou třeba trh rozhodne jinak.

Argument, že o důležitých věcech rozhodují přerostlé děti či (obecně) nesprávní lidé, slýchám často a odpovídám na něj jednoduše: Vydělávat na lidské blbosti je legální. Když někdo během svého používání Windows třikrát řeší reinstalaci viry zničeného systému a pak si stejně zase koupí novou verzi Windows, je to sice úsměvné, ale já si vždycky řeknu: Vždyť on za to platí DPH! A díky tomu DPH budu pak třeba já jezdit novým trolejbusem nebo chodit po lepším chodníku. Snažím se prostě myslet pozitivně. Pro velké firmy kupující špatný software to platí dvojnásob.

[freshmouse]

Vydělávat na lidské blbosti je legální.

Souhlasím; tohle jsem nedávno říkal i na Rootu:

Vydělávat na blbcích není trestné a řekl bych, že to je i celkem hezké. Klidně bych na nich vydělával taky.