Kampaň za záchranu MySQL

Michael "Monty" Widenius, zakladatel MySQL, spustil kampaň (jejíž součástí je petice za zachování tohoto databázového systému) s názvem "Zachraňte MYSQL!", která má za cíl informovat o rizicích spojených s pohlcením Sun Microsystems společností Oracle. Tvrdí, že by Oracle získal příliš velkou moc nad databázemi a mohl by toho zneužít. Spoustu otázek s tímto tématem spojených zodpověděl také ve svém blogu.

30.12.2009 08:05 | Tomáš Heger (geckon) | Komunita

Komentáře

[Amarok]

Doporucuju precist reakci od jednoho z programatoru PostgreSQL tady. Taky mi prijde divny, co si ted tvurci MySQL stezuji, tak to holt muze dopadnout, kdyz se jedna firma proda druhe. Ale cerne to nevidim, bylo by snad myslitelne "odpojit" MySQL a vytvorit nejakou odnoz (?).

[x]

Presne tak. Je tu urcite PostgreSQL, Oracle sam ma free verzi Oracle XE a navic uplne free Berkeley DB, dale tu jsou SQLite, Firebird a jine. I kdyby bylo nejhur, tak vzdy bude alternativa ke ktere se presunou vyvojari nebo vytvori novou. Ale zase chapu, ze to je jeho ditko, tak potrebuje okolo toho kricet. Nemel prodavat no

[dad]

...Je tu urcite PostgreSQL ...

v tom poslednim odstavci (issue->customers pay the bill) je ale vpodstate vsechno receno. Pomoci MySQL mohli cetni vetsi uzivatele (firmy) vytriskat z Oracle vetsi rabaty, protoze hrozili, ze prejdou na MySQL. Prosim uvedomte si, kdyby hrozili, ze prejdou na Postregsql, tak se ten marketing clovek od Oraclu utloukl smichy.

Prosim, v techto otazkach odhlednout od toho, jake trigerry me u jake databaze vice vyhovuji. Zde je o trzni otazky.

[Käyttäjä 11133]

Bych chtěl vidět co by teda ten sales man od Oracle dělal jak by mu někdo řekl, že pokud nedostane slevu, tak přejde na MySQL, to by se smál týden v kuse, ne? :D

[Kandzej]

Marek Stopka: International Man of Business.

[Michal Kubeček]

…protoze hrozili, ze prejdou na MySQL. Prosim uvedomte si, kdyby hrozili, ze prejdou na Postregsql, tak se ten marketing clovek od Oraclu utloukl smichy.

Tuhle úvahu bych prosil trochu osvětlit.

[Shadow]

Přidávám se, také se mi to nějak nezdá.

[Amarok]

Tam neni co vysvetlovat, nahodny kolemjdouci chtel jen na sebe upozornit.

[dad]

ja jsem trochu prekvapen, co je treba objasnovat. Ale budiz:

od roku 2005 se mnozi pripady, kdy uzivatele, kteri neprovozuji SAP ale spravuji velke objemy dat zacali posilhavat po 'levnjesich' resenich. Napr. Neckermann pro svou webowou aplikaci zahodil sybase, protoze jiz zastarale a dalsi vyvoj drahy a rozhodoval se co vzit. Je treba rict, ze to bezi na 30 servrech a samozrejme ze byli ve hre vschni ti velci. MySQL priletela ze Sveddska a nabidla reseni, ktere nikdo nemohl odmitnout. Z diskuzi vim, ze rada kolegu i z mensich firem hlasila, ze pro okrajova db-reseni se nasazuje mysql.

Jestli to tedy neuniklo, reseni s MySQL nabizela firma s milionovym kapitalem, se stovkou zamestnancu a pobockami po celem svete. To jsou argumenty pro management. A Monty to samozrejme vi, prootze ty cisla tech akvizic mel mesicne na stole. Nechci se nikoho dotknout, ale kdybych chtel provozovat Postrgesql v Cechach , tak bych musel pana Stehuleho zamestnat, nejlepe jeste s Kotalou a Zakem z Brna. Ale koho by oslovili pak ti ostatni uzivatele? Ja bych my kone nepujcoval. A to vi i Oracle nebo i IBM a proto by se valeli po zemi, kdyz by nekdo hrozil s Postgresql.

Rad bych jeste doplnil, ze u tech vsech jednani vubec nikoho nezajima, jestli ma mysql trigerry a jestli innodb umi fulltext.

[Käyttäjä 11133]

Proč by provoz SAPu měl být relevantní když se vybírá databáze na webovou aplikaci? SAP snad běží na nějaké speciální licenci pro Oracle, takže lidi nemusí kupovat licenci na Oracle a navíc na SAP, ale jen na SAP a licence na Oracle je v ceně té licence na SAP, ale jako samotný database engine se použít nedá.

se stovkou zamestnancu

Oh, jak velká korporace :))))

[yac]

Pokud by se člověk od Oraclu v takovém případě utloukl smíchy, tak by ho měli vyrazit, protože PostgreSQL je skvělá databáze a Oracle je blíže, než MySQL. K vyslovení tak nehorázné blbosti bys měl mít dobrý důvod, protože by jí mohl nezasvěcený čtenář uvěřit.

Mýtům o rychlém jednoduchém přívětivém MySQL a pokročiljším stabilnějším ale pomalejším PostgreSQL už snad nikdo nevěří. Od té doby oba DBS ušly mnoho cesty - MySQL přibylo spousta vlastností a PostgreSQL zrychlilo. Můžu spekulovat, že PostgreSQL zvládá lépe extrémní konkurentní zátěž a poruchy železa a MySQL je rychlejší v základních operacích, ale to je tak všechno.

[yac]

...o tržní otázky.

Ok, dám si facku a budeme dělat, že jsem nic nenapsal.

[bbp]

Hmmm, to je na fórech tak vzácná reakce, že tleskám.

[okbob]

Vytvořit fork databáze sice možné je, ale udržet jej při životě stojí příliš - snad jedině Google nebo RedHat by dokázaly ufinancovat vývoj. Dnešní O.S. databáze jsou už mají takovou složitost a objem, že vývoj je možný více-méně pouze s týmem full-time vývojářů. Pokud by Oracle neměl zájem na rozvoji MySQL, tak je docela pravděpodobné, že MySQL pomalu zmizí během pěti-deseti let. Precedentů je tu několik - Informix, Interbase.

Legislativně to možné je - k tomu také slouží GPL, myslím si, že je to spíš nepravděpodobné. Aktuálně se šetří, kde se dá. Převzetí několika desítek mega kódu není nic snadného. Některé části kódu MySQL jsou zralé na kompletní revizi - což by fork prodražilo. Navíc revidovaná (a odlehčená verze MySQL) Drizzle spadla do klína opět Oraclu. A jestli jsem pochopil správně, tak dokumentace k MySQL není pod GPL.

[Amarok]

Ale PostgreSQL prece taky nepatri 1 firme a je financovano z nekolika zdroju (firem, dobrovolniku), jestli jsem to pochopil spravne. Takze ta odnoz MySQL by se tak snad dala taky financovat, kdyby se nekdo ujmul cele koordinace. Ale jestli je dokumentace pod poklickou (ve vlastnictvi Sunu/Oraclu), tak je to asi ztraceny, to si teda pan "Monty" sam podrezal vetev.

[okbob]

To, co jsem napsal, ohledně financování, platí jak pro PostgreSQL tak MySQL. Dnešní vývoj je extrémně drahá záležitost.

Vývoj PostgreSQL je o dost nezávislejší a rozptýlenější než u MySQL - už jen z toho důvodu, že nikomu nepatří a patřit nemůže. Další a dost významný rozdíl je ve financování - většina MySQL vývojářů je financovaná centrálně, u PostgreSQL je cca desítka různě velikých firem, které financují své vlastní vývojáře. Takže u PostgreSQL "nejsou" finance až tak důležité - centrálně se řeší jen náklady na infrastrukturu. V podstatě všechno funguje už setrvačností.

U nového projektu by to mohl být problém. Vývojářů zase tolik není (těch schopných) a IT je v útlumu. Ještě před pěti lety se bez problémově (ve větších firmách) ušetřili vývojáři pro interní nebo O.S.S projekty. Nikdo nijak zvlášť neřešil efektivitu. Jsem docela skeptik - teď se po nákladech docela jde. U projektů jako je Pg nebo MySQL se toho už moc nevymyslí, aby bylo možné prodávat přidanou hodnotu - byznys příští dekády bude nejspíš v cloud db, tudíž se nedá čekat návratnost investice. Ale dost možná, že jsem jen už starý morous a pesimista.

[no name]

No on Monty postavil celou licencni politiku a vse kolem MySQL tak, aby to bylo co nejtezsi forknout, aby se to nedalo jednoduse prevzit. Tzn. dokumentaci neni pod GPL a nelze ji forknout, commiteri byly pouze zamestnanci MySQL a tak podobne. A ted se mu to vratilo jako bumerang. Takze dobre mu tak.

[xkucf03]

Dokumentace se přinejhorším přepíše, důležité je, že zdrojový kód je pod GPL a tudíž to provždy bude svobodný software. Potíž je spíš v tom, jak sestavit tým lidí, kteří by se o ten „fork“ starali, a z čeho je platit.

[Michal Kubeček]

důležité je, že zdrojový kód je pod GPL a tudíž to provždy bude svobodný software

A to je právě ten problém. GPL je u podobného projektu pro firmu, která by chtěla vývoj zaštítit, zajímavá v situaci, kdy mohou licencovat duálně GPL+closed, jako to dělá MySQL AB a řada dalších. A to tady nepůjde.

[xkucf03]

Duální licencování může dělat jen firma, která ji vlastní – tedy Sun/Oracle. Když jim MySQL prodali, tak co se dá dělat? Může si na tohle vůbec někdo racionálně stěžovat?

[Michal Kubeček]

Racionálně ne…

[Marv-CZ]

Interbase je naopak příkladem, že zaniknout nemusí. Když už se Borlandu (nebo jak se v té době jmenovali) nevyplatila, otevřel zdrojáky, dal ji k dispozici komunitě a pod názvem Firebird jde vývoj vesele dál.

[Amarok]

Jenze rozsireni se bohuzel rovna (skoro?) nule, alespon u webhostingu. Je to skoda, zakaznici by meli mit moznost vetsiho vyberu. Nebo se Firebird ani nehodi pro weby?

[Michal Kubeček]

Hodí se pro ně velmi dobře - a nejen pro ně. Jenže je to klasický začarovaný kruh. Všude MySQL, všude hromady tutoriálů o MySQL, takže začátečník často ani netuší, že to není ani jediná ani nejlepší možnost. A když už se jednou naučí MySQL, necítí potřebu si rozšířit obzory. Takže všichni chtějí MySQL a poskytovatelé služeb poskytují většinou jen MySQL.

[Michal Kubeček]

Jenom bych ještě doplnil, že rozšíření Firebirdu není zdaleka tak malé, jak by se zdálo podle těch webhostingů. Jen je prostě méně vidět.

[Zdeněk Burda]

Na webhostingu máme od začátku provozu MySQL i PgSQL a PgSQL používá 1,5 člověka z 1000 jinak všichni jedou na MySQL

[Shadow]

Řekl bych, že to je důsledek dlouhotrvající nízké rozšířenosti Postgresu v rámci webhostingových služeb. To působí na vývojáře (nejen FOSS) webových aplikací, kteří v řadě případů sice podporují MySQL, ale už ne Postgres (nebo jsou s ním problémy třeba u pluginů). Druhou stranou mince jsou pak samotní webmasteři, kteří si díky tomu na MySQL zvykli, a Postgres jim nic neříká. Výsledkem pak je, že uživatelů Postgresu na hostingu je minimum.

No, alespoň svou maličkostí v této smutné statistice Postgresu pomáhám.

[Michal Kubeček]

Na druhou stranu je potřeba si uvědomit, že v případě Interbase byly dost specifické podmínky. Především se na vzniku Firebirdu podílela podstatná část (nebo spíš většina) klíčových vývojářů Interbase, kteří byli už delší dobu rozladěni přístupem Borlandu/Inprise/whatever k ní. Navíc byla Interbase naštěstí zveřejněna ne pod GPL, ale pod licencí, která byla zajímavější pro firmy, které by chtěli Firebird podporovat. Díky tomu mohl např. vzniknout Yaffil (který se později s Firebirdem sloučil), díky tomu se také o Firebird zajímala třeba SAS, která pak část své práce poskytla původnímu projektu. A konečně přístup Borlandu (nebo jak se zrovna jmenoval) k Interbase se ani poté nijak výrazně nezměnil a dá se říci, že Interbase byla i nadále na okraji jeho zájmu a vyvíjel ji spíš natruc týmu okolo Firebirdu než že by to s ní myslel nějak vážně.

Tím nechci samozřejmě tvrdit, že u MySQL by fork být úspěšný nemohl. Jen chci naznačit, že Firebird měl od samého počátku několik příznivých okolností, které nejsou zdaleka univerzální, a že tedy nelze automaticky předpokládat, že každý podobný fork bude stejně úspěšný (a úspěšnější než uzavřené pokračování původního projektu).

[Michal Kubeček]

Zajímavé je, že bije na poplach přesně ten, kdo má sám nejvíc másla na hlavě. Nebyl to on, kdo zvolil model financování vývoje, který umožnil investorům udělat to, co se nakonec stalo? Nebyl to on, kdo se rozhodl zvolit duální GPL+closed licencování, které nyní (jak sám správně podotýká) komplikuje možnost vytvoření forku někým "zvenku" (což je dnes už i on sám)?

[qwertzuiop]

Mě na tom zaujaly ty titulky: "Oracle can have Sun but not MySQL" nebo "Help keep the Internet free"...

Monty se montuje do věcí, který mu už neříkaj pane, a nedá pokoj a nedá...

[dad]

ta vec se tyka nas vsech, monopol je treba potirat jak se jen da.

[Filip Jirsák]

Jenže koupě MySQL Oraclem nijak nezměnila to, zda na trhu databází existuje nebo neexistuje monopol. Monopol vůbec nezávisí na tom, kolik je na trhu výrobců, ale na tom, jak snadno je možné na trh vstoupit a jak snadno se trh zbavuje těch, co neuspěli.

[Shadow]

Monopol vůbec nezávisí na tom, kolik je na trhu výrobců

"Monopol" je, dle definice, forma nedokonalé konkurence, kde na straně nabídky figuruje jen jediný výrobce. Tudíž na počtu výrobců záleží v první řadě - je-li jeden, můžeme mluvit o monopolu, je-li jich více, monopol to není.

[Filip Jirsák]

Taková definice je ovšem úplně k ničemu, protože na počtu výrobců na trhu vůbec nezáleží. Pokud existuje na trhu monopol (v tom významu, který používám já a který se zpravidla pod slovem „monopol“ myslí do té doby, než někdo začne hledat definici ve slovníku), často je na trhu jen jeden výrobce. Ale ten počet výrobců není příčina, ale jen vedlejší efekt.

[Shadow]

Problémem je, že když si každý bude redefinovat odborné termíny po svém, nebudeme si vzájemně rozumět, protože si každý pod takovým pojmem představí něco jiného. Je pouze vaší iluzí, že pod pojmem monopol vidí každý přesně to, co vy.

Ano, ta definice je k ničemu, protože nepopisuje to, co chcete říci. Ale to ani není jejím smyslem a není to smyslem pojmu "monopol". Je sice hezké, že se snažíte nějak pojmenovat problém, pro který neznáte příslušný odborný termín, ale použitím jiného termínu, který označuje něco jiného, entropii příjemce vaší informace příliš nesnížíte. Mně třeba není jasné, co přesně máte na mysli. Můžu tušit, ale jistě to nevím, protože jste neposkytl ani vaší vlastní definici problému, ale ani odborný termín, který by ji popsal. Vy jste tomu vašemu problému jenom řekl "monopol", protože to byl nejbližší termín z dané oblasti, který jste znal. Jenomže ten označuje něco jiného, než o čem mluvíte. To je pak těžké...

[dad]

ja bych rad jeste neci doplnil:

pouzil jsme nahore monopol a to i presto, ze sam tu definici neznam. Jenom mi neco naseptava, ze fima Oracle ma jakesi rozhodujici postaveni na trhu, kdyz za vsechny vydane penize za databaze jich dostane prave Oracle 70%. Jestli maji rozhodujici nebo dominantni nebo jake postaveni na trhu tedy nevim. Samozrejme, ze jsem s Vami, ze kdyz se snazime argumentovat , tak bychom meli byt presni, myslim si avsak, ze to v kratkosti diskuze proste nejde. Nemohu nejdrive vybudovat moji argumentativni platformu a na techto zakladech pak dal dokladovat. Zde jsou diskuteri 'povinni' kooperativne interpretovat', co je 'asi' mysleno.

[okbob]

Narazil jsem na trochu jiná čísla - "On its earnings call last night, Oracle president Charles Phillips crowed about IDC data showing Oracle’s database share at 44.3% vs. 21% for IBM vs. 18.5% for Microsoft. (údaj je z loňského léta)". V případě relačních databází nelze mluvit o tom, že by tu jeden dodavatel výrazně dominoval, případně že by deformoval trh. Většina IS obsahuje podporu jak pro Oracle, tak pro DB2 nebo pro MSSQL. Samozřejmě, že integrátoři protěžují Oracle, protože mají větší rabat.

[dad]

ano, co se celeho trhu tyce mate pravdu, ta aktualni cisla jsou zhruba porad takova. Ja to samozrejme palim od boku a ted nevim, jestli to nebylo nahodou jen v oblasti unixu? Presto, kdyz se podivam na nejaky clanek , kde ta cisla prezentuji, tak v nadpise vetsinou stoji, ze Oracle dominuje trh s databazemi, proto jsem se nechal asi strhnout mluvit o tom monopolu.

[bpbp]

asi chtěl říct oligopol to je celé http://cs.wikipedia.org/wiki/Oligopol

[Filip Jirsák]

Nechtěl jsem říct oligopol, chtěl jsem říct monopol a to ve významu, v jakém se tohle slovo běžně používá – tedy dominantní postavení jednoho nebo několika subjektů na trhu, kdy tyto subjekty dokážou s trhem nějakým způsobem manipulovat. Tedy ve významu, kdy se říká, že má monopol Microsoft, tři čeští mobilní operátoři, ČEZ atd. Bavíme se tady totiž o ekonomice, takže nemá smysl používat termíny a jejich definice z teoretické ekonomie, které se v praxi v této čisté podobě nevyskytují. Tahle debata má asi stejný smysl, jako rozčilovat se nad pojmem „vakuová obrazovka“ nebo „vakuové WC“, protože fyzikálně „čistého“ vakua přece nejde dosáhnout.

[Ladicek]

Help keep the Internet free

Je konečně třeba říct, že SQL se na web nehodí. Nedá se očekávat, že by lidé nějak brzy procitli, ale mastodonti databázového světa si pod sebou řežou větev sami. Ve jménu flexibility: nechť zhyne král!

[Michal Kubeček]

Je konečně třeba říct, že SQL se na web nehodí.

Podobné výkřiky mají pro reálný svět asi takovou hodnotu jako prohlášení Andrew Tanenbauma, že je Linux úplně špatně navržen, protože nepoužívá mikrokernel, nebo výkřiky, že celá unixová koncepce je úplně špatně a jedinou spásou je Plan9.

[Miloslav Ponkrác]

SQL se na web hodí perfektně.

Jinak jsem přesvědčen, že makrojádro v unixové koncepci je špatně – i když v době vývoje Linuxu bylo dobře. Nicméně mikrojádro není nutné řešení. Je možné najít jakékoli řešení, které začně reflektovat fakt, že desítky miliónů řádek zdrojového kódu jádra nelze udržet bezchybné a je nutné chránit i části kernelu mezi sebou. Nemusí to být nutně mikrokernel, ale vývoj IT směřuje tímto směrem.

[Ladicek]

Musím říct, že mi přímo lichotí, když mne srovnáváte s takovými makáči Což ovšem nic nemění na mém přesvědčení, že pro typicky webové aplikace (redakční systémy, zčásti i webové obchody, sociální shítě) není SQL vůbec to pravé, protože data obvykle mají nepředvídatelnou a hodně volnou strukturu.

Ne že by to nebylo off topic, ale chtěl jsem trošičku přilejt do ohně ještě nevyzkoušený olej

[Miloslav Ponkrác]

A cílem programátora i databázisty je dát této volné struktuře řád a pravidla. S nedomyšleným chaosem volných dat se dá pracovat pouze jen fulltextem a tím jste skončil.

[Ladicek]

Cílem programátora je co nejlíp splnit požadavky zákazníka. Data je samozřejmě potřeba strukturovat, ale co hodláte dělat, když tu strukturu prostě předem neznáte? Mimochodem fulltext je moc pěkná věc a takový fulltextový index se dá docela jednoduše přiohnout k databázovému použití

[Miloslav Ponkrác]

A ke splnění cíle je třeba vykonat další akce, které jsou prostředkem k tomuto cíli. A jedním z prostředků je eliminovat maximum chaosu jak ze zadání od zákazníka, tak z volnosti formátu dat.

Pokud neznám předem strukturu dat, tak dokopu zákazníka k dalším informacím. Mimochodem, ještě se mi za 25 let programování nikdy nestalo, abych dostal nulové informace o struktuře dat.

[Ladicek]

Jo, jo. Jedna věc je programovat informační systém, kterým protékají stovky miliard korun ročně ( ), a druhá věc je programovat web, kde je pro vás klíčová schopnost co nejrychlejší změny (třeba když máte těch zákazníků víc a každý má požadavky jiné).

[Miloslav Ponkrác]

Máte smůlu, že jsem programoval obojí. Stále si stojím na svém.

Prostě pokud se naučíte programovat jako prase, pak už to jednoduše jinak neumíte a myslíte si, že je to nejlepší a nejefektivnější způsob.

Mám mnoho let zkušeností a řeknu Vám, co přesně dělám, když je něco potřeba naprogramovat rychle. Sednu si k papíru, nebo jdu venčit psa a zabývám se rozmýšlením, jak co nejlépe udělat architekturu data programu/webu/aplikace. Výsledkem je, že celý problém se drasticky zjednoduší a naprogramuje mnohem rychleji i se započtením času na tuto analýzu.

A o rychlých úpravách nad tímto systémem už vůbec nemluvím. Čím prasečtěji naprogramovaná věc, tím déle a dražší jsou úpravy.

[Ladicek]

Fakt by mě zajímalo, proč už tady několik lidí usoudilo, že schéma není v databázi = prasení, to spolu přece vůbec nesouvisí. Flexibilita v nakládání s daty možná v někom vzbuzuje bázeň přímo nábožnou (s chutí do toho pokřižování, jestli máte pocit, že vám to pomůže ), ale to je tak všechno. Když po mně někdo chce "přidej políčko takový a makový", tak opravdu nevidím důvod přidávat sloupečky do tabulky a nedej bože ještě do pohledu (a nechoďte na mne s ORM, to má svoje vlastní problémy ). Teda u toho webu – u nějakého důležitého systému naopak budu rád, že mi databáze dá možnost dalších vynucených kontrol, přístupových práv, transparentních transformací a podobně.

[Bubak]

Nepracoval jsi na tomhle projektu?

http://thedailywtf.com/Articles/Classic-WTF-The-Storray-Engine.aspx

[Miloslav Ponkrác]

Jestli mohu mluvit za sebe, tak na prasení jsem usoudil z více faktů. Upřímně to, že schéma není v databázi je něco, co by mě ani nevadilo.

Možná si to neuvědomujete, ale třeba ty poctivě navržené datové struktury dávají ve většině případů daleko větší flexibilitu. Daleko větší možnosti práce s daty a umožňují s daleko menší námahou najít/zjistit/vypočítat potřebné údaje.

I samotná relační databáze umožňuje velmi flexibilní strukturu a velmi volnými datovými strukturu bez jakýchkoli předpokladů. Relační databáze není nic, co by člověka omezovalo nijak zvlášť v rozletu a implementaci i velmi fantastických a kreativních možností uložení dat.

Jenže takto chaotická data jsou na hovno a schválně jsem použil tento termín. Jejich užitečnost je minimální.

Myslím to, že prasíte zcela vrcholově došlo každému, kdo trochu něco s programování vážně dělal. A to daleko dříve, než jste začal mluvit o schéma mimo databázi. Asi tak jako každý dirigent pozná falešný tón a nenaladěné housle. Přímo to z Vašich příspěvků od prvního přímo bije do očí.

[Miloslav Ponkrác]

Jinak rád bych dodal, že Vás osobně nechci nijak urážet jako člověka a nic proti Vám nemám.

Ale Vaše metody rozhodně nejsou správné, ani efektivní, jsou prostě k ničemu. Spíše tedy jen upozorňuji na fakt, že byste měl zkusit jiný způsob.

[alblaho]

Relační databáze člověka nijak neomezuje, dokud člověk nepotřebuje strom . Nebo dokud vám stačí výkon jednoho stroje.

Miroslave, mícháte dvě věci: kvalitní analýzu a lpění na relačních databázích. Absence druhého podle Vás implikuje absenci prvního. Což je samozřejmě blbost.

Navíc Ládíček ani nerozporuje, že pro důležité věci (třeba práci s penězi) se věci jako referenční integrita hodí. Ale pro blogísek a redakční systém to rozhodně není priorita.

[okbob]

Cílem bastlíře je co toho co nejvíc nabastlit.

Je mi záhadou, jak můžete programovat něco, co dopředu neznáte.

[deda.jabko]

Je mi záhadou, jak můžete programovat něco, co dopředu neznáte.

problem je, ze clovek casto dopredu nektere veci nevi... typicky... zakaznik pri testovacim provozu zjisti, ze by chtel neco trochu jinak... dalsi problem nastava, kdyz je potreba aplikaci rozsirovat a pokud mozno, co nejrychleji to jde, protoze to muze znamenat konkurencni vyhodu....

[Bubak]

Doufam ze nikdy nebudu muset udrzovat tebou napsanou aplikaci.

[okbob]

hmm ... a v čem je problém?

Když už, tak to není problém SQL, ale relačního datového modelu. I když spíš bych to viděl na problém mezi klávesnicí a židlí.

[Ladicek]

Ale jo, do takové relační databáze se dá narvat všelicos, a databázisti si vlastně ani neuvědomujou, že to bolí Jak tu databázi, tak programátora. On třeba není problém navrhnout strukturu, do které lze uložit dokument s předem neznámým počtem a typem položek (a někteří do dotahují tak daleko, že nad relační databází vlastně implementují dokumentovou databázi), ale jestli je tohle ta pravá cesta, no, to ať si každý rozhodne sám.

[okbob]

To není problém relačního modelu, ale nešikovných rukou.

Vůbec není problém generovat strukturu databáze dynamicky. S pohledy, případně s podporou partitioningu se fakt už nic nemusí hnácat do jedné tabulky. Tak jako tak, v určitém okamžiku strukturu znát musíte. A teprve v ten okamžik můžete vytvořit tabulku, a pomocí pohledů nebo partitioningu tuto tabulku zapojit do struktury.

[Ladicek]

Jo, jo. Vy začnete vytvářet tabulky a nad nima pohledy – a já už mám hotovo. Moje datové schéma je součástí aplikace a nepotřebuju ho hustit ještě do databáze

[okbob]

To je možné, ale v okamžiku, kdy přijde požadavek na opravu nebo úpravu, tak já budu mít hotovo, a Vy ještě budete přesvědčovat zákazníka, že ta úprava je vlastně zbytečná.

[Miloslav Ponkrác]

Mám vnitřní touhu se začít pokřižovat.

[xkucf03]

A deklarativnost nepovažuješ za výhodu? (ve srovnání s tím, že nic deklarované není a je potřeba to hledat v kódu nebo v datech)

[alblaho]

Generovat strukturu modelu dynamicky, partitioning, udělat pohledy... Opravdu se ti to nezdá trochu složitější, než to být musí? Já myslím, že kdo má trochu filozofického nadhledu, tak tam tu bolest cítí.

[okbob]

Přiznám se, že tam tu bolest necítím, ale dost možná, že je to proto, protože sestavení JOINu mi nepůsobí žaludeční nevolnost. Je jasné, že NoSQL db (db bez schématu) je INSERT jednodušší - v podstatě uložíte někam dvojici klíč-hodnotu. Větší trivialita snad existovat nemůže. Ovšem operace, které s takto uloženou informací můžete dělat jsou také triviální. V jedinou operací je získání hodnoty na základě klíče. Cokoliv jiného znamená komplikaci - zvlášť, pokud data nejsou v RAM.

[alblaho]

Já mám trochu pocit, že mě máte za blbce. Join mi taky nevolnost nepůsobí, svého času jsem dělal tiskové sestavy, kde se spojovalo až 13 tabulek a dokonce jsem to dovedl poskládat tak, že to bylo rozumně rychlé (a btw, dělal jsem na tom s Ládíčkem). A bavilo mě to.

Ale stejně tak mi má inženýrská intuice říká, že na redakční systém by dokumentová databáze ala CoachDB fungovala možná i lépe, ověřeno to nemám, protože všude mám PostgreSQL. Bylo by to o něco jednodušší, potenciálně lépe škálovatelné...

Taky mám rád, když data mají řád, že mám dokumentovou databázi neznamená, že v ukládání dat není systém. Abych se z toho nezbláznil, tak tam musí být nějaké příčetné entity a rozumné vztahy mezi nimi.

Kvůli škálovatelnosti velké weby používají maximálně tak MySQL jako filesystém (Facebook), Google má infrastrukturu vyloženě v oblacích (GFS, BigTable), eBay dospělo k tomu, že ty slavné JOINy dělá v aplikaci. To jsou extrémní případy, uznávám, ale je to minimálně důkaz, že SQL se nehodí na velké weby.

[Ladicek]

Pokud jde o eBay, tak ti vůbec dospěli k různým věcem. V LinkedIn postavili key-value store nad MySQL, ve Facebooku zase zkombinovali Dynamo s BigTable , a tak by se dalo pokračovat. Pokud jsem to dobře pochopil (zdrojáky jsem moc podrobně nestudoval), na svého druhu dokumentové databázi (s relačním backendem) běží i Ábíčko. K něčemu podobnému časem dospěje spousta projektů. Ovšem ty patnáctitabulkové reporty mi ani nepřipomínej

[okbob]

Možná, že každý trochu meleme svoje a nějak se míjíme.

Ano, vím na čem zhruba běží facebook, a vím, že řada velkých webů používá databáze, které označujete jako NoSQL. Ovšem vyvozovat z toho, že SQL db se nehodí na velké weby je ničím nepodložené. Navíc se tu bavíme o webech, co se týče návštěvnosti, tak v ČR nemají obdobu. Vím o konkrétních zdejších webech, které jsou leadery ve svých oborech, které jedou nad db (ať už je to MySQL nebo PostgreSQL) a nemají nejmenší výkonnostní problém (dokonce, když se zeptám adminů, jak jede pg, tak dostanu odpověď, že se pg fláká a že o něm více-méně nevědí). Takže Vaše tvrzení minimálně není pravdivé a jako důkaz stojí za starou bačkoru. Na co se relační db nehodí, tak je uchovávání dočasných dat s velice krátkým životním cyklem. Což v případě webu jsou např. sessions, na což se parádně hodí memcached.

Když se podívám na CouchDB, tak co vidím - jednoduchý storage, jednoduchý management, který jednoduše umožní zápis dat, jednoduše umožní získání dat, ale cokoliv jiného, už Vám dá více práce než v SQL databázi. Je to v podstatě klasická db, s jednou tabulkou. To, že umí variabilní záznamy není nic světoborného, - moderní db to umí také. Zajímavý je interface. Samozřejmě, jedná se již o specializovaný návrh - kdežto klasické SQL databáze jsou univerzální. Ano, souhlasím, pro správu dokumentů je např. CouchDB výhodná - ma takový interface, který by si programátor s velkou pravděpodobností sám musel napsat. Ale již pro cokoliv jiného, než je správa dokumentů, bude CouchDB ojeb. To je prostě výhoda/nevýhoda specializace. Vyvozovat z toho, že na DMS se univerzální db nehodí je nesmysl. Ale je pravdou, že na DMS se databáze specializovaná na DMS hodí více. Prostě Vaše argumentace mi přijde trochu jako demagogie. Už např. pro eshopy bude použití CouchDB minimálně diskutabilní.

Jedním z argumentů proti SQL db byla statičnost struktury. Zase, pokud budete mít jednoduché DMSko, tak pravděpodobně Vám bude jedno, co je v datech. Pokud budete mít firemní DMSko - např. FileNet a pod. si strukturu budete těžce vynucovat, protože bez toho byste za chvíli měli v db bordel. V tom okamžiku bude pro Vás pracnější používat NoSQL db než klasickou SQL databázi.

Možná tu působím jak konzerva, která nechápe přínos těchto db. Pro mne nejsou ničím zvláštní - v podstatě specializované db, tu byly odjakživa. Je jasné, že když je nasadíte v určité doméně, tak Vám přinesou benefit, ale v okamžiku, kdy se dostanete za jejich specializaci, tak máte problém. Navíc tyto db až na výjimky nemají něco co by se dalo označit za "human interface". Pokud s nimi chcete pracovat, tak kromě triviálních úloh, chca nechca musíte programovat.

Na druhou stranu, teď už se opakuji, mnohem raději vidím NoSQL db než SQL db s ORMkem. V obou případech se používá radikálně ořezaný interface. ORMko je ve většině případů zbytečná neužitečná a občas i škodlivá zátěž. Uznávám, že pro některé programátory může být šok, jak může být rychlá db, pokud ji nebrzdí ORM. Trpím, když vidím programátory řešit problémy, které by vůbec řešit nemuseli, pokud by nepoužili ORM a s db pracovali přímo. Takže pro řadu programátorů budou NoSQL db přínosem, ale to nic neříká o relačních nebo SQL databázích.

[alblaho]

Já v podstatě souhlasím, netvrdím, že CoachDB spasí svět, protože jsem ho ani nezkoušel.

Ale zaujal mě poslední odstavec. Webové frameworky jsou _plné_ ORM. Já momentálně používám Django, a jsem s ním spokojen. Používáme i CMS nad tím - DjangoCMS - a to dává tomu postgresu dole dost pokouřit, každá stránka vygeneruje až 40 SQL dotazů. Takže mně nemusí nikdo povídat, že ORM má své limity; takhle brutálně deoptimalizované to nechávám, protože zatím to server stíhá.

Jenže nějaká forma ORM je vždycky potřeba (protože OOP je mainstream), záleží jen na úrovni jeho abstrakce. A právě proto, že žádné SQL už ručně nepíšu si říkám, jestli je mi tahle vrstva k něčemu.

Vlastně jediné SQL, co píšu ručně jsou úpravy schématu

[okbob]

Abstraktní vrstva nad SQL nemusí být realizována pouze prostřednictvím ORM. Viděl jsem implementaci založenou na datových proudech. Vznikají lehčí ORM, která netrpí problémy jako má např. Hibernate. Asi se shodneme na potřebě abstraktní vrstvy nad DB - minimálně by SQL dotazy měly být nějak soustředěny do jednoho místa. Nevím jestli se shodneme na tom, že by programátor mel ovládat SQL, přestože používá ORM. ORM by měly programátorům šetřit práci, nikoliv za ně myslet - tady mám určité pochybnosti. Navíc - použití určitých ORM vede k takové struktuře databáze, která blokuje jakýkoliv jiný přístup než prostřednictvím ORM, čímž použití obecné databáze ztrácí smysl. U SQL databáze je důležitý návrh - pokud vývojář neumí psát dotazy z ruky nebo je mu to nepříjemné, pak pravděpodobně návrh db je nedobrý. Setkal jsem se s tím, že takový návrh byl ovlivněn i použitým ORM. ORM je super na komplexní málo objemná data - např. uložení stavu GUI aplikace. Na cokoliv jiného bych se už docela rozmýšlel, tuplem při velkých objemech (cca nad 10M db).

Po určitých negativních zkušenostech s ORM fakt nejsem ten pravý, kdo by se tu mohl vyjadřovat k ORM. Narazil jsem na článek http://pichlik.sweb.cz/archive/2009_11_01_archive.html#5867716946020959897, s kterým se dokáži ztotožnit.

[xkucf03]

Navíc - použití určitých ORM vede k takové struktuře databáze, která blokuje jakýkoliv jiný přístup než prostřednictvím ORM

Jakých ORM? To myslíš, případy, kdy si někdo napíše třídy (nebo ty taky vygeneruje) a k nim si vygeneruje schéma databáze? Tohle je IMHO nešťastné řešení (byť rychlé a někdy uplatnění najde), ale rozhodně ne jediné – můžu mít seriózně navrženou databázi, pak si napsat třídy a pak mapování (xml/anotace). Je to sice víc práce, ale i tak to bude asi méně práce než psát všechny DAO třídy a jejich metody pro ukládání a načítání dat (to je hrozná otrava a pořád dokola – vzít vlastnosti objektu, nastrkat je jako parametry SQL dotazu, dotaz spustit, nebo vzít výsledek SQL dotazu a jednotlivé jeho sloupečky rozstrkat do getterů daných objektů… hrozná nuda, od které nám může ORM pomoct). Osobně mám na ORM dost nevyhraněný názor, někdy se hodí, někdy ne a občas si pohrávám s kacířskou myšlenkou, že lze oba přístupy v jedné aplikaci kombinovat

[xkucf03]

Jenže nějaká forma ORM je vždycky potřeba (protože OOP je mainstream), záleží jen na úrovni jeho abstrakce.

Pod ORM si představím primárně věci typu Hibernate – ne nějaká (často jednoúčelová) údělátka namaštěná v PHP. Pokud si někdo píše datovou vrstvu (a SQL) ručně, tak je to prostě DAO vrstva a ne žádné ORM (byť z toho na jedné straně lezou objekty a na druhé straně je napojená databáze).

Vlastně jediné SQL, co píšu ručně jsou úpravy schématu

A kdo píše ty SQL příkazy? Jaký konkrétní produkt? Nebo nějaký jiný programátor?

[xkucf03]

On třeba není problém navrhnout strukturu, do které lze uložit dokument s předem neznámým počtem a typem položek

To v relační DB není problém – ať už přes dědičnost, nebo obecněji přes M:N vazební tabulku. A těch typů je vždycky konečný počet.

někteří do dotahují tak daleko, že nad relační databází vlastně implementují dokumentovou databázi

V tabulce v relační databázi si můžeš vytvořit třeba jeden sloupeček do kterého nacpeš XML data. Tím získáš obrovskou flexibilitu (XML snese všechno) + vyspělé nástroje, které jsou často i integrované do databáze (XPath…), a přitom čerpáš i z výhod relačních databází (co jde strukturovat, máš jasně a přehledně strukturované).

[Michal Kubeček]

Musím říct, že mi přímo lichotí, když mne srovnáváte s takovými makáči

Nemělo by. Oboje jsou příklady úvah, které jsou sice za určitých teoretických předpokladů správné, ale ty teoretické předpoklady ignorují natolik velkou část reality, že závěry z nich plynoucí se se skutečností naprosto míjejí. Dříve jsem byl toho názoru, že hlavní důvod, proč se ve větším měřítku prosadil právě Linux a ne jiné open source operační systémy, byl ten, že přišel v ideální možnou dobu (rozšíření 80386, nástup Internetu); dnes už jsem přesvědčen, že přinejmenším stejnou váhu má Linusovo praktické a pragmatické založení.

[jehovista]

A co navrhujes? Nejakou genialni formu semanticke databaze? Pokud vim, tak pro implementaci takove databaze se porad na nejnizsi urovni pouziva SQL. Nebos myslel neco jineho?

[Ladicek]

Tak některé RDF databáze asi běží na relačním backendu (teď koukám, že třeba i Virtuoso, to jsem ani nevěděl), ale spíš se používají specializované triplestores, pokud vím. Jinak jsem měl na mysli spíš dokumentové databáze a podobné věci.

[dad]

jsem rad pane kolego, ze do tech rel/sql databazi rezete, ja uz to delam leta. Bohuzel ale znam ten vyrok od pana Plancka, ze jista, zajeta akademicka presvedceni nelze vymytit argumenty, tato presvedceni zmizi az z biologickym koncem jejich zastancu. Musime si priznat, nase snaha je marna.

[Ladicek]

Jsem mladej a blbej, marná snaha Spíš si říkám, jestli ty moje bláboly tady nejsou natolik povrchní a nepřesné, že lidi spíš odpudí. Na druhou stranu, stejně jako dnešní webaři nepůjdou přesvědčovat lidi od informačních systémů, aby začali podporovat jejich MySQL, nepůjdou ani lidi od informačních systémů do Googlu, aby pro svoje vyhledávání použili jejich Oracle

[deda.jabko]

nepůjdou ani lidi od informačních systémů do Googlu, aby pro svoje vyhledávání použili jejich Oracle

to by ses divil... uz jsem videl clanky od ,,odborniku'' na databaze, kteri tvrdili, ze map-reduce je naprosto nevhodny zpusob, jak zpracovavat data...

[Ladicek]

To jsem taky četl! MapReduce: A major step backwards, MapReduce II. Vtipný je třeba bod 2, MR nepoužívá indexy – bodejť, MR je způsob, jak ty indexy vytvářet Ale vůbec nejvtipnější je The Scoop on Hadoop and Vertica: Last month Vertica announced support for MapReduce.

[deda.jabko]

ja jsem cetl neco uplne jineho, ale ty argumenty byly obdobne... vicemene, to bylo stylem, jako kdyz nejaky expert na zive.cz recenzuje linux... mimochodem, hezka paralela k tomu, jak se do tebe vsichni pustili kvuli tomu, ze chces pouzivat i neco jineho nez relacni db...

...a ty si pritom neuvedomujes, ze relacni db pouzivaji vsechny aplikace... stejne jako, ze vsechny aplikace bezi na windows a neni duvod pouzivat linux, protoze ten ma prikazovou radku a prikazovou radku pouzivaji jenom zaostali jedinci na zaostalych operacnich systemech, atd., atd., ...

Tady mate mensi prehled jinych databazi: http://nosql-database.org/

Tady mate nejake prednasky k databazim z vyse uvedeneho odkazu... https://nosqleast.com/2009/#speakers

Kdy konecne lide pochopi, ze relacni databaze se nehodi na vse a rozhodne nejsou univerzalni a zaroven, ze to neni synonymum pro slovo databaze.

[dad]

no jo, ale tohle by si meli hlavne precist ti docenti a profesori na fakultach informatiky, tam odtud ty bludy vsechny prichazeji.

[Miloslav Ponkrác]

Ještě že Vás máme! Bez Vás bychom byli zcela ztraceni.

[okbob]

Ona většina těch projektů pochází z fakult informatiky, takže si myslím, že páni profesoři minimálně tuší o co běží. Jestli to chápu správně, tak se jedná o obdobu síťového modelu. Většina NoSQL databází je založená na hash tabulkách, některé Vám garantují persistenci dat, většina nikoliv. Výhody nevýhody: - výhody:, v podstatě snadný insert, snadné vyhledání unikátních položek, nevýhody: pomalé hromadné zpracování dat. Nic nového to není. V podstatě je to technologie, která byla k dispozici v 60 a 70 letech, a teď se k ní můžeme vrátit, protože se zvětšují kapacity RAM.

[Miloslav Ponkrác]

Ono by to asi chtělo ujasnit si pojem „databáze“.

V zásadě ukládat data musí každý program. I program na výpočety kvadratické rovnice o několika řádkách zdrojového kódu ukládá data. Pokud lokální proměnné na stacku pro uložení reálných čísel nazveme úložištěm dat, neboli databází, pak i takto se to dá vzít.

Různé speciální databáze založené na jiném, než relačním principu se samozřejmě používají celkem běžně a nikomu nebrání je zvolit. Používají se souběžně s SQL databázemi.

Nicméně nevidím jediný důvod, proč SQL databáze zavrhnout. Základní problém je, že žádná NoSQL databáze nedá záruky (enterprise záruky) jako dávají některé SQL databáze. Další problém je, že z hlediska rychlosti a univerzálnosti při obecném zpracování (zejména velkého množství) dat žádná NoSQL databáze nedotáhla na úroveň SQL. Jednotnost SQL jazyka je také velké plus, stejně tak jako nezávislost na programovacím jazyce a operačním systému klienta, kterým k SQL DBMS přistupujete.

Základním problémem je, že třeba pro OOP databáze se jaksi napodařilo ještě najít obecný standard multijazykového dotazovacího jazyka. Problém je, že všechny NoSQL stále nejsou ve stavu, kdy je to až na výjimky něco jiného, než kutění. Většinou nic hotového, dotáhnutého, se všemi standardy, API, ovladači a knihovnami. Mluvím zejména o věcech pro větší projekty.

Na druhé straně pro embedded aplikace jsou NoSQL používány velmi často. Je jich obrovská řada. Často paradoxně takové databáze po čase vývoje vyvinou SQL rozhraní.

Třeba jsem se setkal s velmi obchodně úspěšnou databází, která je určena pro ukládání měřených hodnot. Ve skutečnosti ukládá časový průběh měřených hodnot a uvnitř jsou ukládány křivky ve formě parametrů interpolovaných funkcí. Třeba tento typ databáze na té stránce NoSQL není. A i tento typ databáze vyvinul pro některé účely SQL driver pro použití SQL jazyka. Měl jsem ho tehdy programovat já, ale chtěl jsem zůstat v domovině a nepřesídlit natrvalo někam jinam a mluvit už pouze anglicky, což byla podmínka.

Podle mého se tu zbytečně hrotí konflikt, který si kdosi vycucal z prstu. Nikdo nikomu nebrání používat NoSQL databáze, jen bude v řadě případě převálcován zcela po zásluze konkurencí, pokud to bude dělat bez ohledu na situaci a potřeby.

[okbob]

Jinak, kdyby Vas tema NoSQL databazi zaujalo, tak pokud se neco nepokazi, tak na p2d2 2010 4.unora bude NoSQL databazim venovana jedna prednaska. Zatim jsem domluven s prednasejicim, nicmene mi jeste neposlal podklady, ktere by bylo mozne vystavit. Doufam, ze po novem roce anotaci naleznete na http://www.p2d2.cz/.

[Amarok]

Bude pak nekde videozaznam? Tema me zajima (i treba jine prednasky z te konference), ale nechce se mi tam prijet.

[okbob]

Zaznam asi bude - ale po zkusenostech z predchozich rocniku nebude hned.

[dad]

bude to obecne k NoSQL nebo k nejakemu urcitemu reseni ? (ja vim, ze bych mohl pockat do ledna, ale jsem zvedavy )

[okbob]

Tohle zalezi na prednasejicim.

[KaiSVK]

No ... tak mam asi stastie, moj profesor na DBS povedal "...v sucasntnosti najrozsirenejsim typom databaz su relacne databazy" a ja som uz vtedy, ked to vyslovil vedel ze je to mudry clovek :)

[xkucf03]

Proč tam nejdeš učit ty, třeba bys to dotáhl i na profesuru

[okbob]

Pokud máte takový objem dat, že se Vám data vejdou do paměti, nebo naopak pokud máte tak málo paměti (embeded) zařízení, tak pak SQL databáze nemusí být to pravé ořechové, to uznávám. Klidně můžete mít data v některé formě hash tabulky, případně grafu. Proč ne. Pravděpodobně v cloudech se nebudeme setkávat s klasickými relačními databázemi - pravděpodobně tam ACID kritéria budeme chtít také - i když D bude mít dost možná jiný význam.

Teď jde o to, co Vám vadí - zda je to normalizovaný model, nebo neprocedurální dotazovací jazyk. Normalizovaný model se nepoužívá např. nepoužívá u objektových db. Nicméně i u objektových databází je nutná datová analýza. Tedy dopředu si rozmyslet strukturu, schémata, vzory. Nemusí jít o kompletní UML analýzu. Stačí si ujasnit co a jak bude vypadat. I obyčejný truhlář, když staví králíkárnu, tak si udělá schémátko, rozkreslí si půdorys, spočítá si míry, a podle toho si nařeže prkna. Pokud to má nějak vypadat. Nebo pak někdo musí být geniální, a to je pak škoda, že se zahazuje s obyčejnými weby.

[Michal Kubeček]

Kdy konecne lide pochopi, ze relacni databaze se nehodi na vse

Ale oni to chápou… Jenže když začnete vykřikovat věci jako "Je konečně třeba říct, že SQL se na web nehodí.", je to úplně stejný nesmysl, jako kdyby někdo jiný tvrdil, že se skvěle hodí na všechno. Jistě, jsou projekty, kde se nehodí. Ale pro řadu aplikací se hodí velmi dobře a pro většinu webových aplikací se hodí dostatečně dobře na to, aby jejich nasazení bylo (ne nutně jedinou) dobrou volbou.

Zkuste se podivat treba na CouchDB nebo Riak. Potom vam dojde, co tim autor toho citatu myslel. V tomto pripade asi lepsi je CouchDB.

[Miloslav Ponkrác]

My víme, co tím autor myslel. Že je levej jako šavle a snaží se to na něco hodit, v tomto případě na SQL databáze.

[alblaho]

Hm, tak to až zase budu hackovat nějakou DB ve Firebirdu, tak asi půjdu tahat rozumy z někoho jiného. Když je levej, prasí a vlastně ani žádnou produkční relační databázi (určitě!) neviděl.

[Michal Kubeček]

Vypadá to sice zajímavě, ale moc mne to nepřesvědčilo. Tam, kde jde jen o webové rozhraní, to asi své výhody mít bude, ale u naprosté většiny aplikací, na kterých jsem pracoval, tomu tak nebylo. Navíc je potřeba vzít v úvahu, že často nemusí být správným řešením najít jazyk (framework, engine, ...), který se pro daný typ úlohy bude hodit nejlépe, protože mohou rozhodovat i další faktory, třeba zkušenosti, dostupnost a kvalita pomocných nástrojů, dostupnost lidí, kteří s tím umějí pracovat atd.

[OnOff]

Ládíček je prostě boží!

[Amarok]

Uz toho Ladicka nekdo umlcte! To se fakt neda cist. Pul dne sem nekoukam a ted vidim same stezovani o tom, jak je slozite neco delat v SQL, kdyz se predem nevi, co se ma vubec delat. To je snad logicke, ne?

[Ladicek]

Omlouvám se vám všem a slibuji, že od nového roku přestávám s programováním a jdu si udělat MBA.

[Amarok]

To prave neprestavej, naopak konecne zacni opravdu programovat :)

[Ladicek]

To jsem samozřejmě napsal špatně, moje chyba, omlouvám se velmi pěkně, zejména těm, kteří nad mými výroky obraceli oči v sloup a spínali ruce v modlitbě ke sv. Coddovi. Tam mělo být napsáno "ohavným prasením".

[dad]

ale no tak, lide kteri se modli k SQL Vas prece nemohou tak rozhodit. Uvedomte si prosim jedno:

je to jak po revoluci, pocitam ze za 5 let tady bude komentar pana Ponkrace o tom, jak muze byt nekdo tak hloupy a jeste pouzivat SQL.

Udelal jste dost, alspon se o tom mluvi, to ted staci, je to treba nechat ulezet. Vsiml jste si, jak si ti zastanci SQL presto 'pro jistotu' nakoukli ty stranky s tim NOSQL, aby jim 'nahodou neujel vlak'. Klidne se usmivejte pod vousy (jestli tedy uz nejake mate ) a prominte mi muj otcovsky poucny ton.

[Ladicek]

Spíš to zkusím takhle: teď mi tu bylo prokázáno (davem) totální prasečkářství (cítím se jako za starých časů, kdy jsem si v PHP bastlil vlastní redakční systém ), takže zřejmě nastal čas, abych o tématu napsat článek. Nebo možná rovnou seriál…

[dad]

v tom pripade apeluji na vase socialni citeni a rad bych videl, aby ten serial vysel na linuxsoftu, jak jste se mohl dovedet nedavno, pan Kysilka se musi starat o nemocnou pritelkyni a nema moc casu psat sam ...

[mich]

Po drobném googlení mám pocit, že jste ten člověk co nám letos na KIVu v rámci TSI přednášel o bezchémových databázích, je to tak? Každopádně kdybych nevěděl o co jde, tak podle vašich příspěvků v téhle diskusi bych opravdu měl pocit, že jste matlal. Přimlouvám se za seriál (alespoň na blogu), zkuste tomu dát formu, je to zajímavé téma.

[Ladicek]

Ou, jsem odhalen! Tak mám pro vás jednu dobrou radu: ukázalo se, že jsem matlal, takže raději zapomeňte všechno, co jsem vám říkal. Je to infekční!

[okbob]

Proboha - NoSQL databáze nejsou nic nového. O paměťových db se mluví cca 4 roky - minimálně s nástupem facebooku a podobných portálů. Memcached se běžně používá. Pokud programátorům nevyhovuje SQL, pak mi přijdou NoSQL databáze logičtější než ORM. Zatím, jestli jste si všiml, Vám většina NoSQL db negarantuje persistenci a konzistenci dat (pokud ano, tak db musíte provozovat v podstatně pomalejším režimu). To dost omezuje použitelnost, nezdá se Vám. Řešením je provoz v clusteru. Ok - já jsem si zatím nevšiml, že by běžné weby jely v cloudech.

O čem mne ale nikdo nepřesvědčí je nutnost datové analýzy před samotnou realizací. To co tu Ládínek předvádí je styl naslibovat hory doly, a pak až při realizaci zjistit, co zákazník chce. Což si někdo může vykládat jako úžasnou adaptabilitu nebo, jako já, jako ukázku amatérství par excelence - kdy po několika měsících kódování zjistí, že zákazník chce něco jiného.

[Ladicek]

Proboha, že slibuju hory doly a že měsíce kóduju bez interakce se zákazníkem jste našel kde? Hm, kdybych byl aspoň včera opilej To už teda není vůbec o databázích, ale o stylu vývoje. Já spíš než na dlouhé analýzy věřím na rychlé prototypy a spíš než na dokonalost na první pokus věřím na rychlé iterace s nedílnou účastí zákazníka. Teda pokud je to možné, samozřejmě. O čem jsem se snažil mluvit je spíš situace, kdy rozvíjíte software několik let a nutně narazíte na požadavky, které jste nemohl předvídat a které vyžadují fundamentální změny datového modelu (což teda není přidání jednoho políčka, ale třeba lokalizace dat, když mám uvést něco obecného). Myslím si, že na webu je taková situace hodně častá, myslím si, že schopnost rychle ji vyřešit a nevynucovat přitom okamžité změny v datech a v celé aplikaci je důležitá, a myslím si, že existují databáze, které jsou k tomu mnohem líp vybavené než SQL. Já nevím, líp už to asi říct nedokážu.

[alblaho]

Já čím jsem starší a blbější, tak na analýzu věřím čím dál míň. Prostě si fakt nevěřím, že bych postihl všechny detaily v analýze, přitom ďábel se skrývá víme kde.

[Yenda]

?Mám ďábla po boku, pořád vím, že tu je, jak nehmatatelný vzduch kolem mne se plouhá...

Ladicek prostě neustále a tvrdošíjně předbíhá dobu. Třeba jednou bude patřit do všeobecných vědomostí IT specialisty, že relační databáze se nemusí tvrdošíjně cpát všude. A že se XML nemusí cpát všude možně. Taky bez ohledu na to, jestli se na to XML hodí. Páč když XML, tak s DTD schématem, čili XML je dobré ;) Jak je to s tím zatloukáním hřebíku a hledáním kladiva?

[deda.jabko]

taky by sis mohl laskave uvedomit, ze jedine spravne webove aplikace se pisou v J2EE (i kdyz vsichni vi, ze nejrychlejsi programovaci jazyk na svete je C++, protoze ma uplne nejvic nejrychlejsi syntaxi) a data se skladuji jenom v Oraclu, protoze jak nemas data ulozena v oraclu, tak davas data svych zakazniku vsanc. jo, taky by sis mel uvedomit, ze pokud tva aplikace neni z poloviny napsana v XML nebo XSLT, tak jsi totalni prase. :-]]

[Milan Jurik]

Takze podle pana Wideniuse se MySQL a Oracle DB prekryvaji a konkuruji si v temer vsech oblastech pro zakazniky. Za to IBM DB2 vubec ne. Jezisi, ono mu tohle opravdu cele jeste nekdo veri?

[Michal Kubeček]

Bohužel asi ano. Zajímavější by ale bylo vědět, jestli tomu věří on sám.