Vlákno názorů k článku
MySQL v roli neschémové databáze

Arthure, tohle: „Vývojáři začínají často narážet na omezení relačních databází, jejichž návrh je sice časem ověřený, ale přece jen poněkud staršího data.“ je pokud o zvýšení čtenosti, nebo je to myšlené vážně?

Já jen že (až na možnost uložení libovolné struktury) jsou relační databáze povětšinou podstatně méně omezené, než key-value storage. Srovnávat databázi a storage je jak srovnávat náklaďák a porsche – náklaďák se hodí na 100* víc věcí, porsche jen rychle jezdí.

<flamebait>

Mě osobně (ač je mi nosql sympatické) přijde, že se z nosql dělá posvátná kráva neskutečných rozměrů, občas slyším výkřiky (ne od tebe), že sql je překonané a že budoucnost je v schema-less storages. Leda prd, relační databáze jsou 1. podstatně silnější (kolik jazyků podporuje postgre? 7? 8? a kolik k-v storages? jen javascript), 2. lépe podporované (skutečnými firmami, ne skupinkami geeků po 3 lidech), 3. vhodnější na 95 % aplikací (tedy všude tam, kde není nutné pracovat s terabajtovými objemy dat), 4. pokryté mnohem lépe vývojářskými nástroji, 5. dostupné na levných hostinzích, 6. něco málo v nich napíše i ta největší lama, co si myslí, že databáze = relační.

Těším se, až tenhle buzz skončí, těch 5 %, co schema-less užije, si je bude používat, dalších 95 % bude dál používat sql a svět bude spokojený a natěšený na další hurráábuzz (třeba nohtml – to bych se možná i zapojil).

</flamebait>

NoSQL neni pro kazdeho. Je to pro firmy, ktere maji mysql na 100+ serverech a potrebuji snizit naklady na HW a administraci.

Pokud aplikace nepotrebuje nutne ACID operace a nepotrebuje relacni DB, da se takto usetrit i 75% nakladu. Musite byt ale dostatecne velka firma, ktere se to vyplati, a ktera ma na to lidi (admini, programatori).

Pokud se bavime o provozu na nejakej sdilenem hostingu, tady je NoSQL IMHO jen nepotrebny offtopic a kazdej se o tom bavi jen proto, ze je to cool :)

zajimalo by me, jak se pozna, ze aplikace potrebuje relacni DB.

Třeba tak, že uchovává relační data a jiný formát databáze/storage (stromová, k-v) je jen ohýbání. Těžko to můžu podpořit nějakou statistikou, ale troufnu si říct, že drtivá většina aplikací, které kdy vznikly, vznikají a v budoucnu vzniknou, budou uchovávat právě relační data.

Používat na tato data cokoliv jiného je drbání levou nohou za pravým uchem. Jde to, ale…

Jiří, stejně tak je křížovým drbáním napasovávat veškerá aplikační data na relační model. Jen nám to tak nepřipadá, protože to děláme automaticky a podvědomě. Troufnu si říct se stejnou sebedůvěrou jako ty, že většina webových aplikací, které kdy běžely nad *SQL, uchovávají relační data jen proto, že je tak někdo navrhl, a navrhl je tak proto, že měl k dispozici právě jen *SQL stroj.

Martine, já napasovávám relační model na relační data.

Když dostanu uložit stromovou strukturu a mám jen sql databázi, taky u toho nadávám jak čert.

Není jediný důvod, proč ukládat relační data jinak než v relační databázi (pokud těch dat nemám terabajt). Relačních dat je většina.

„Relačních dat je většina.“ – dokaž! Tedy lépe řečeno – dokaž, že „relačnost“ je jejich přirozená vlastnost!

Velmi jednoducho. Analyza sa totiz robi tak aby z toho nakoniec relacny model vypadol ;-).

Asi tak nějak. :)

Jinak aby nedošlo k omylu – s tvrzením „není důvod ukládat relační data jinak než do relační databáze“ plně souhlasím, jen se mi zdá, že argumentace se točí v kruhu: Data jsou relační proto, že je někdo jako relační popsal, a popsal je tak proto, že je bude ukládat do relační databáze!

Ale zas uvadzane riesenie je scestne lebo tiez vyuziva relacnu databazu. A to vsetko iba preto ze operacia pridania stlpcia a pridania indexu dlho trva? Tak to sorry, to nie je chyba relacneho modelu.
Ak raz niekto vytvori databazu kde pridanie stlpcia pripadne vytvorenie indexu pojde rychlo tak si mozu trieskat hlavu o mur.

Četl jste nepozorně:

„Což nás v důsledku nutilo vyhýbat se přidávání takových funkcí, které by vyžadovaly změnu struktury nebo indexů. A protože se od doby, co jsme databázi rozdělili, staly „relační“ funkce jako třeba JOIN naprosto nepoužitelné, rozhodli jsme se porozhlédnout mimo svět relačních databází.“

„MySQL funguje. Nepoškozuje data. Replikace funguje. Známe její omezení. Máme rádi MySQL jako úložiště dat, ne kvůli tomu, že je to relační databáze.“

Ale opat to su technicke problemy nie chyba relacneho modelu. My robime aj s vacsimi tabulkami ako sa tu popisuje. Oracle, partitioning. Databazu sme delili ale tak aby to malo logicky zmysel. Takze udaje ktore patria spolu su spolu.
Kompletne udaje o zamestnancoch mozete mat v jedenej databaze a relaciu k nim v inej pripadne dolezite udaje vytiahnete koli JOINom aj do druhej databazy.
Uzavierky aj tak musia bezat offline. Fakt si myslim ze toto NoSql nema ziadny zmysel.
Existuje na to cely odbor ktory sa tym zaobera ETL.
http://en.wikipedia.org/…nsform,_load

Pripadne duplikaciu udajov vyriesite v aplikacnej vrstve (ha-jdbc, sequoia). V kazdom pripade mi pride jednoduchsie ako toto riesenie ktore urobili oni.

Důvodem pro relační model není ukládání dat, ale způsob práce s daty.

Problémem je, že hodně lidí chápe relační databáze (doslova pouze) jako uložiště a pak si z nich zákonitě dělají druhý souborový systém.

No jo, jenže tohle se ve škole neučí – tam tě učí, že máš začít datovou analýzu nezávisle, bez nějakých předsudků, zda to bude relační, objektová nebo hierarchická či jiná databáze. V druhém stupni, na základě předchozího, rozhodneš, který z těch modelů to bude, který vyhovuje nejlíp. A až ve třetím kroku vybereš konkrétní implementaci SŘBD*. Jenže to by lidi tyhle poučky nesměli považovat za akademické kecy a nesměli by hned po první schůzce začít črtat tabulky (nejlíp rovnou jako CREATE TABLE v konkrétním dialektu).

(na druhou stranu stejně by člověk ve většině případů vybral zase tu relační…)

*) třeba ten Oracle „za který ještě nikoho nevyhodili“ nebo MySQL, „protože s ní děláme odjakživa“, nebo PostgreSQL, protože je to nejlepší z open sourcu.

Vybral by „tu relační“, protože je na ni zvyklý. Dost možná by už při analýze nepřemýšlel „jaká databáze to bude“, ale „jak to bude v relační databázi“. Protože relační databáze máme, známe, jsme na ně zvyklí, a zvyk je minimálně železná košile, když ne rovnou posvátná kráva. :)

… tam tě učí, že máš začít datovou analýzu nezávisle, bez nějakých předsudků, zda to bude relační, objektová nebo hierarchická či jiná databáze. V druhém stupni, na základě předchozího, rozhodneš, který z těch modelů to bude, který vyhovuje nejlíp …

to je jeden z nejvetsich problemu informacni technologie, totiz, ze se na svet diva skrze projekcni bryle. V drivejsich odvetvich to take bylo tak, i auto staveli panove Benz a jini pred sto lety na zakazku a staveli se k tomu jako k projektu. Toto mysleni pretrvava v IT dodnes a proto se muze SQL stale drzet. V projektu se totiz nevidi, kde se utopi ty naklady, projekty jsou z principu prodelecne at uz je to web nebo elektrarna. Vzdycka to stoji 2 x tolik a trva to 2 tak dlouho. Z techto duvodu jeste nikomu nedoslo, ze SQL je jednim z tech velkych problemu

Polehoucku se ale objevuji prvni vlastovky (pan Maly) , kteri si dovoli prohlasovat. ze SQL neni posvatna krava. Brzy se jiste dovime i proc.

Nene, relačních dat je menšina, podle různých studií tak max 5%. Většina dat je nestrukturovaná nebo semi-strukturovaná. Relační model realitu dost ohýbá, pro většinu aplikací je např. mnohem vhodnější datový model XML.

Toto je bludne tvrdenie. Kde je ta statistika? Vacsina veci ma totiz vztahy typu N:M co musite aj v XML vyriesit iba smernikom cez identifikator – relacia.

Clovek MA napriklad pecen co ide v XML pekne ale keby som robil SW pre nemocnicu tak by som kazdy organ radsej drzal vo vztahu k cloveku cez relaciu lebo ked ju niekomu preoperuju tak XML asi bude nevhodne.

„Vacsina veci ma totiz vztahy typu N:M“ – protože je ukládáte do relačních databází, tak jim tyto vztahy přisuzujete (musíte, jinak byste je tam neuložil). Mimochodem, kolik pacientů bude podstupovat transplantaci jater (pečene, že? Ledviny jsou jinak…), aby to OSPRAVEDLNILO napasování do relačního modelu „člověk – orgány“? A které orgány budete takhle oddělovat do různých tabulek? Všechny? Proč? Je prohazování orgánů mezi pacientama tak častá operace, aby ospravedlnila rozbití logického celku (člověk) do relačního modelu?
I kdyby šlo o transplantační oddělení nemocnice, tak není nutné ani lepší použít relační model. Mohu klidně (a logičtěji) použít entitu „člověk“, které dám atribut „darce_jater“ – a v něm bude druhá entita „člověk“. Mně to připadá logičtější než rozštípnout člověka na „schránku“ a „orgány“.
Pokud ale budu v situaci, že v zadání bude „Běh na MS SQL serveru“, tak je logické, že z toho ty relační vztahy udělám. Ale to není argument, to je pouze setrvačnost.

A teraz pride zlaty klinec – reporting. To ako budete pisat tie dotazy, filtre agregacie (pouzitim SQL?)? K tomu vasmu systemu neexistuje aparat ktory z relacnym model suvisi. Robit to systemom citania filov z blobov mi opat pride ovela nepohodlnejsie, pomalsie, neflexibilnejsie, narocnejsie.
Boli tu uz objektove databazy, XML databazy, … . Ja osobne robim z Javou takze napriklad objektove databazy su pre mna vhodnejsie riesenie. Nakoniec ale narazite na problemy a zistite ze SQL je zakladom vsetkych na ktorych mozete stavat. Urobit XML databazu nad SQL ide. Tak isto ako ide vytvorit NoSQL databazu nad SQL :-D.

„Robit to systemom citania filov z blobov mi opat pride ovela nepohodlnejsie, pomalsie, neflexibilnejsie, narocnejsie.“ – problém je v tom, že „vám připadá“, a to je taky celé jádro sporu. Jiní nedali na svá „připadání“, zkusili to – a vyšlo jim něco jiného, tak se o poznatky podělili.

A o tom (a o ničem jiném) je celý článek. Můžete ho číst jako zajímavou zkušenost, která vás třeba přiměje zkusit své „připadání“, „dojmy“, „dobré důvody“ a „jednoznačné pravdy“ oprášit a zrevidovat, nebo ho můžete vzít jako útok na posvátnou krávu, kterou je potřeba bránit. To už nechávám na vás.

Ne není, jen naráží na mentální bariéru mozků, které jsou posledních třicet let trénovány na relační model dat. Pokud jste vystudoval nějakou IT školu, jste analytik nebo děláte s databázemi, máte zkrátka praxí zkreslený pohled na věc. Neříkám, že to je dobře nebo špatně, ale je to tak.

Když se řekne faktura, představí si člověk postižený databázemi několik tabulek – pro hlavičku, pro odběratele, dodovatele, položky faktury, … a jak je to pěkně provázané vztahy.

Normální člověk si při vyslovení slova faktura představí takový ten papír – zkrátka fakturu. V případě použití datového modelu XML stačí okolo informací na „papírové faktuře“ doplnit elementy a máte vystaráno. XML nemá problémy s opakováním údajů, s hierarchickou strukturou atd. XML reprezentace faktury je mnohem bližší skutečné faktuře než její relační datový model.

Konec konců podívejte se na to, co většinu času dělá aplikace pro vystavování faktur, které se ukládají do relačního datového modelu. Asi zjistíte, že to je mapování mezi tím, jak faktura vypadá pro potřeby vstupního formuláře nebo naopak výstupní sestavy a tím, jak to rozkouskovat a zase poskládat z několika tabulek.

Statistiku stačí vygooglit, je to všeobecně uznávaný fakt, jen se liší odhady mezi 80–95% (pro nestrukturovaná data), např.:

http://clarabridge.com/default.aspx?…

Co když zjistím, že u jedné firmy mám překlep v adrese a potřebuji ho opravit u všech faktur? Nebo že název zboží na půlce faktur neobsahoval důležitou informaci, kterou chci doplnit?

Jednou z hlavních výhod relačního návrhu (v 3NF) je to, že jsou všechna data uložena právě na jednom místě (kromě primárních klíčů, které by měly být neměnné).

Pokud bych naznačený scénář chtěl realizovat s XML dokumenty, tak si tam ty tabulky a relace taky musím navrhnout a do XML je schovat.

Tak zrovna 3NF je pro účetní doklady naprosto nevhodná, protože ty není možné zpětně v čase modifikovat (pomíjím tedy možnost, že by se do tabulek přidala ještě dimenze času, která by říkala v jakém okamžiku byla daná adresa platná, což by relační datový model a dotazy ještě pěkně nafouklo).

Samozřejmě, pokud je to z povahy problému potřeba, můžeš něco jako relace (odkazy na jiné XML nebo jeho části) používat. Výhoda datového modelu XML je v tom, že když se to hodí, nemusíš spolu související data zbytečně rozbíjet do několika tabulek a jde s nimi pracovat najednou jako s jedním celkem.

„Tak zrovna 3NF je pro účetní doklady naprosto nevhodná, protože ty není možné zpětně v čase modifikovat“

Mně to ale nepřijde jako něco v rozporu s normální formou. Údaj (adresa) na faktuře k nějakému datu je prostě jiný údaj než adresa v aktuálním adresáři firem. Řešit to odkazem, cizím klíčem, IMHO není lpění na normální formě ale obyčejná hloupost (odkazujeme se někam, kam bychom neměli).

„možnost, že by se do tabulek přidala ještě dimenze času, která by říkala v jakém okamžiku byla daná adresa platná“
Je to jedno z řešení. Druhou možností je mít jednu adresu pro každou fakturu – ani tak to nemusí být denormalizace dat – stačí se na to dívat tak, že adresa k 2010–01–07 11:28 je svébytný údaj a je to něco jiného než adresa (k jiné faktuře) k okamžiku 2010–01–07 11:35. Je to něco jako naměřené hodnoty třeba z teploměru – jednou jsme naměřili 10°C, za hodinu naměříme zase 10°C, ale taky to nebudeme řešit cizím klíčem na nějaký jeden záznam…

„XML reprezentace faktury je mnohem bližší skutečné faktuře než její relační datový model.“

A není ta faktura (jakožto kus papíru) také jen modelem reality? I když je to model nepočítačový – ale zachycuje nějaké vztahy (někdo někomu něco prodal – kolik, čeho, kdy…).

Ale je fakt, že třeba účetnictví založené nad eXistem by mohlo být zajímavé a asi by to fungovalo (aspoň do nějakého objemu dat) tisk a různé exporty by byly efektivnější a přímočařejší, zatímco sčítání a další agregace trochu složitější (než třeba sum() v relační databázi).

Díky. Jak velmi přesně píšete, to „mapování mezi tím, jak faktura vypadá pro potřeby vstupního formuláře … a tím, jak to rozkouskovat a zase poskládat z několika tabulek“ je právě to, co je na současném stavu tak zoufalé. A to přestože to mapování děláme přes nějakou abstraktní vrstvu ORM. (Mimochodem, bylo by príma, kdyby sem napsal někdo, kdo takovou abstraktní vrstvu píše, abychom tady viděli někoho, kdo má _skutečně_ důvod být na dominanci *SQL hodně, hodně naštvaný :)

Přesně tenhle příklad s fakturou funguje jako hlavní use-case pro úvod do CouchDB (a tím pádem zprostředkovaně pro MongoDB, etc etc): http://books.couchdb.org/…/why-couchdb#…, citace:

> An invoice contains all the pertinent information about a single transaction; the seller, the buyer, the date, and a list of the items or services sold. As shown in Figure 1–1, there’s no abstract reference on this piece of paper that points to some other piece of paper with the seller’s name and address. [zvýr. KM]

Já mám spíš problém, že by měl být někdo hodně naštvaný spíš na filozofii OOP, které chybí background pro hromadné operace. Což zase umí databáze. Tady jde o dva rozdílné světy, a z toho vychází všechny kolize. Na jednu stranu by programátoři rádi používali OOP, na stranu druhou díky OOP nelze řešit hromadné operace. Databáze jako CouchDB ten problém do jisté míry eliminují – v tom se podobají MySQL – jednoduché operace umí velice rychle.

Problémem není dominance SQL. Problémem je nepokrytí určité oblasti filozofií OOP. Případně rozpor mezi dvěma neslučitelnými systémy – OOP (umí pohodlně pracovat s jednotlivými objekty), RDBMS (umí efektivně pracovat (dynamicky) s velkými množinami dat).

sorry – nepřečetl jsem si to po sobe. Začátek „Někdo by měl být spíš naštvaný na OOP“

p.s. otázky, které tu řešíme, bychom pravděpodobně neřešili, kdyby byly k dispozici OOP databáze. Což je asi ta šedá oblast, která se porůznu pokrývá ORM, NoSQL databázemi, XML databázemi.

Ale objektové databáze k dispozici jsou – ZoDB, GemStone.

Jenom nemají ty výkonnostní, případně finanční charakteristiky. A že objektové databáze spasí svět, o tom se mluví minimálně tak dlouho, jako že svět bude spasen pomocí XML.

Někdy přemýšlím nad přínosem zavádění IS/IT pro život :-) Potenciál pro zlepšení je v přestavbě procesů (která je umožněná novými technologiemi, které dřív nebyly), ne v tom, že vezmeme ty staré procesy a elektronizujeme je (a tak zafixujeme). Tím, že něco „dáme do počítače“ to nebude automaticky fungovat líp. Faktura jakožto dokument odráží prostředky dostupné ve své době – tužka, papír, psací stroj. Odkazovat se v argumentaci na vlastnosti „kusu papíru“ je směšné. Ten papír není nic primárního, je to jen lidský konstrukt, model snažící se zachytit nějakou skutečnost (ta je primární). Pokud chceme dělat věci líp (něž účetní za první republiky) musíme je dělat jinak…

> Pokud chceme dělat věci líp … musíme je dělat jinak
Este ste zabudli ze ked ich budete robit inak mozete ich robit aj horsie. Na to aby ste robili veci lepsie musite poznat ich historiu a dokonca aj s celym okolim ktore na to vplyvalo a snazit sa to napasovat na sucasne podmienky lepsie. Vsetko sa da robit aj lepsie pretoze okolie sa meni ale u historicky preverenych veci je velmi pravdepodobne ze ak ich budete robit inak budete ich robit horsie.
Zoberte si armadu. Hodnosti, utvary, postupy, riadenie. Mozete to robit inac ale s vysokou pravdepodobnostou iba horsie a ak tak iba male zmeny, ziadne zmeny filozofie armady su nepripustne.
Tak to mate aj s relacnymi databazami. Relacna teoria vznikla hrozne davno a je casom overena. Mame tu rozne implementacie a moznosti ako do nej napasovat XML, objektove a vselijake ine udaje (dokonca aj NoSQL :-D). Zasadna zmena je to iste chciet menit podstatu pocitaca, CPU, MEM. Ano mame pokusy s kvantovymi pocitacmi a podobne ale to je dnes uplne mimo misu. Tak ako chciet robit veci INAC.

1) Nepochopená implikace? „líp → jinak“ přece neznamená, že „jinak → líp“.

2) Ne, já nepatřím k fanatickým odpůrcům relačních databází (spíš naopak, když se nedržím na uzdě :-). Tím dělat věci jinak jsem právě myslel oprostit se od toho, že faktura je kus papíru, dokument, celek. Protože ta faktura je jen model reality (sekundární) a když budeme hledat to primární, zjistíme, že tu jsou nějaké entity a vazby (kdo, komu, co, za kolik). XML mám rád, je to skvělá technologie se spoustou využití, ale zrovna pro to účetnictví mi přijde vhodné jen jako formát pro výměnu dat, nikoli pro jejich ukládání – na to se víc hodí ten relační model.

Aha, tak sme sa nepochopili. Takto ako si to napisal teraz to podpisem aj ja.

Jako spoluautor webové aplikace pro správu faktur Fakturoid, který použil PostgreSQL, si říkám: škoda, že tehdy neexistoval MongoMapper :)

Spousta věcí by se řešila elegantněji, řádky by se vložily přímo do faktury, údaje o odběrateli a dodavateli taktéž (hezky jako zanořené objekty, ne placatě, jako to je teď).

Přepisovat to teď není zrovna dobrý nápad, ale v příští aplikaci bych data velmi rád ukládal do něčeho, kde se nemusí neustále migrovat schéma, kde nejsou potřeba podivuhodné praktiky pro rozdrobení dat do tabulek a jejich zpětné scucávání zpátky :)

Předně bych rád pochválil Fakturoid :-) Když jsem na něj koukal posledně, tak byl jen blog, teď jsem konečně viděl, jak vypadá ta aplikace – pěkné, jak vzhledově, tak ten nápad*.

Teď k těm relacím – „Fakturoid je aplikace pro tisk a správu faktur“ – vytvářet a archivovat nějaké dokumenty je diametrálně odlišná aplikace než účetnictví. Když jsem tu psal, že faktura představuje nějaké entity, vztahy, relace… tak to bylo v souvislosti s účetnictvím – to se podle mého bez relační databáze napsat nedá a pokud to někdo dokáže, tak je to frajer (nebo blázen) a má můj obdiv :-)

Aplikaci typu Fakturoidu bych asi psal nad XML databází. Tedy pokud by aplikace neměla ambice vyvinout se časem v plnohodnotné účetnictví. Stejně tak by tahle aplikace fungovala** nad NoSQL databází a jak je vidět, funguje i nad SQL – je to prostě v první řadě o tom nápadu (ten je nejdůležitější) a až teprve potom o technologiích.

*) jen mám trochu pochybnosti ohledně toho, že bych měl svoje data o účetní poskytovat někomu cizímu, ale jistě se najdou lidi, kterým tohle nevadí.

**) fungovala, ale psát bych ji nechtěl.

Sami si odporujete. Aj XML su strukturovane data. A aj XML sa da velmi pohodlne ukladat do relacnej SQL databazy. Vy iba nechcete vidiet to ze strukturovane data nie su iba relacne data a to XML vas hrozne pletie. Takze relacny strukturovany model vasho struktovaneho XML je uplne presne realizovany a XSD nie je nic ine ako inac zapisane DDL pre databazu.

„Toto je bludne tvrdenie. Kde je ta statistika? Vacsina veci ma totiz vztahy typu N:M“

Jenže ta statistika se netýká teoretické podstaty těch (čistých) dat, ale praktické situace – a ty čísla přibližně pravdivá jsou, firmy mají opravdu většinu dat (měřeno objemem) jako nestrukturovaný hnůj a jen zlomek (datovým objemem, ale asi ne důležitostí) strukturovaně. Prostě je to rozpor v tom, jak by to mělo být a jak to je – a je to tak, že opravdu těch nestrukturovaných dat je víc (byť by měla/mohla být strukturovaná).

Jenže to podle mého nebude podstatou těch dat, ale spíš tím, že se lidi ve firmách chovají k počítači jako dříve k psacímu stroji – akorát to místo do šanonů strkají do adresářů a pak končí na terabajtových diskových polích.

Mně zase přijde, že realitu ohýbá XML svojí jednodimenzio­nalizou, ale to ne vždy vadí. Každopádně ale lepší XML (se svými schématy, validacemi, transformacemi…), než k-v noSQL (ne že by nemělo využití, ale IMHO je to okrajová záležitost).

Mr. I love XML se ozval ;) Ale notak pánové, všichni jsme tu tak trochu strůjci svojeho štěstí co ? :)

A to ako kam tie XML data chcete strkat. Na filesytem? Alebo ako BLOBY do databazy? A potom ked vam niekto povie urob report na vsetky faktury ktore nie su plne uhradene usporiadane od najvacsej dlznej sumy tak si to zoberiete ako projekt na niekolko dni a jeho vykonanie bude trvat 2 hodinky. Namiesto toho aby ste usmolil nejaky SQL command pripadne pomocou drag&drop reporting toolu si to pomaly sam urobi uz aj financny riaditel.

Ved vy ludia uplne stracate sudnost. Viete co je hlavny dovod pouzivania normalnych foriem a relacnych databaz? Vsak to nerobime preto ze sa nam to paci. Taky tu uz boli co pracuju s CPU nekonecne rychlou a RAM nekonecne velkou. Nech sa paci nahlaste sa do kurzu LISP-u. Tam uz vsetky vase problemy vyriesili, dokonca rekurzivne.

A to ako kam tie XML data chcete strkat. Na filesytem? Alebo ako BLOBY do databazy?

Většina soudných lidí by asi XML dokumenty pro tento účel strkala do XML databáze (např. eXist).

Alebo ich mozete strkat aj do SQL relacnej databazi (neviem ci viete ze existuju nadstavby relacnych databaz ktore nativne pracuju s XML). XML databaza, objektova databaza, je iba NADSTAVBA relacneho modelu ci sa vam to paci alebo nie. Neodpovedali ste ale na dalsie otazky v mojom prispevku.
Nerozumiem ale naco chce niekto NoSQL databazu. To ako by ste chceli XML data bez XSD, typov a XQuery. Ide to, ale nerozumiem kde je tu pokrok.

mozna s vyjimkou tech, co to uz zkusili…

Co takhle se vrátit zpátky k tomu článku a přečíst si to znovu a pomalu, místo rozčilování nad tím, že „lidi ztrácí soudnost“. Opravdu bych nechtěl, aby diskuse pokračovala na této úrovni, tedy kdo ztrácí soudnost a jak je kdo hloupý, že NEVIDÍ ty argumenty… Děkuji.

To je podle me na programatorovi – musi zvazit ekonomicky prinos toho, ze se opusti relacni DB a aplikace se prepise.
Kdyz to vezmu do extremu, jakakoliv aplikace se da postavit na jednom plaintext souboru, je to jen otazka vykonu, bezpecnosti a nakladu :)

Pokud tyto články povedou k tomu, že se několik lidí zamyslí a zjistí, že SQL není vhodná jako řešení na všechno, tak super. V podstatě každý buzz je o tom, vytvořit nadšení, které umožní vyzkoušet různé alternativy než se najde optimální nasazení technologie.

NoSQL má dost problémů a je dost aplikací kam se nehodí, přesto by znalost jejich principů k vybavení každého vývojáře. Aby nemusel znova vynalézat kolo.

To že SQL byla chycena v nedbalkách a na nároky webových aplikací prostě nestačila je jasné. Teď je jen otázka zda je možné ty enginy změnit. Věci jako zápis pouze na Master, složitý sharding a velmi zajímavá replikace. U původního článku se v diskusi vynořil nějaký pán a začal říkat, že je to celé chyba MySQL a že jiné lepší DB enginy by to zvládly. Otázkou zůstává na jakém železe a kolik stoji?

…zjistí, že SQL není vhodná jako řešení na všechno, tak super. …

problem je, co nasadit misto sql, co vim, existuje jen hrstka produktu, o kterych nema ale bohuzel vetsina populace nejmensi potuchy …

… a proto tu o tom píšeme, aby mělo potuchy víc lidí.

No jenže todle z prominutím není nový produkt, ale znásilnění relační databáze.
Nemám nic proti nerelačním db, ale todle imho šlo lépe řešit dobrou volbou databázového stroje.

Nečtete pozorně:

„Existuje spousta databázových projektů, navržených tak, aby řešily problém ukládání dat s pružnou strukturou a vytváření indexů za běhu (například CouchDB). Bohužel žádný z nich není dostatečně používaný na velkých serverech, abychom se mohli někde inspirovat. V testech, které jsme četli a které jsme si udělali, se žádný z těchto projektů neukázal dostatečně stabilním či otestovaným do té míry, jakou potřebujeme.“

Čet sem diskusi i pod originálním článkem a tam několik lidí navrhuje např. oracle, který s vytvářením indexů on the fly nemá problém.
IMHO autoři toho řešení vzali na danej účel nejnevhodnější databázovej stroj, zjistili že jim nevyhovuje, tak řekli, ahá, databázovej stroj se na to nehodí. Uděláme to tedy jinak…

Ono 250milionů řádků zas není tolik. V podstatě i to, že ten „basmekt“ (byť evidentně chytře a dobře udělanej, ale svojí podstatou bazmekt), kterej nad MySQL napasovali, běží tak rychle, vypovídá o tom, že ty data se daj rozumně zvládnout.

Tím nechci říct, že to jejich řešení není zajímavý, ni že možná z pohledu cena/výkon/rychlost vývoje bylo za jejich současné situace, kdy jim všechno
běží na mysql, jedním z nejlepších ba dokonce nejlepší řešení. Je to ale drbání se levou nohou za pravým uchem.

Konstruktérské pravidlo říká, že není problém, který by se nedal vyřešit kladivem. A pokud pokus o řešení selže, znamená to, že máte malé kladivo.

Tohle je totéž: S trochou nadsázky lze říct, že není aplikace, jejíž datové problémy která by se nedaly vyřešit Oraclem na dostatečně výkonném železe. Ale to ještě neznamená, že to je řešení jediné, natož že je správné.

Tak za 1) bazmekt LOOOOOOOOOOOOOOOL
za 2) Skor mi to pripada ze sice dobre poznali MySQL a zistili ze im nevyhovuje ale nepoznali nic ine. Nikto im neprezradil ze napriklad mame nejaky partitioning a mozno „bazmekt“ vznikol este v case ked partitioning nebol ;-)

Znásilnění je pro mnohé taky prima činnost :-) Ostatně, kolikrát člověk musí znásilnit i Excel nebo OpenOffice aby se dobral požadovaného výsledku :-)

Excel? Pokaždý.
OpenOffice? Pokaždý dvakrát.

Aneb OffTopic flame.

Jiří, ta formulace je reakcí na jednu diskusi tady na Zdrojáku, kde kdosi obhajoval SQL stroje argumentem, že „jsou za ta léta dobře vyladěné“ a že „na jejich vývoji pracují ti nejlepší vývojáři“ (s nevyřčeným „a chcete snad říct, že jste lepší?“). Já proti tomu mohu namítnout, že v době, kdy SQL vznikalo, byl relační model ideálním obrazem tehdejších HW možností. Doba se změnila, priority se posunuly, takže SQL v dnešní době není vždy a za všech okolností tou nejlepší volbou.
Samosebou jsem dalek toho hlásat smrt RDBMS. Ale na druhou stranu si myslím, že relační model není posvátná kráva a že „ideová“ konkurence nezaškodí.

Tak, já nevím, jestli tohle je správná platforma na nějakou diskusi, ale… některé z věcí které píšeš opakují „obecně rozšířené omyly“ a tak by možná stálo za to je proklepnout.

> Leda prd, relační databáze jsou 1. podstatně silnější (kolik jazyků podporuje postgre? 7? 8? a kolik k-v storages? jen javascript),

Mohl bys prosím tohle blíže vysvětlit? (Předpokládám, že se tím „podporuje“ nemyslí to, že se dá s databází pracovat v programovacím jazyce – protože s nimi samozřejmě lze pracovat z prakticky všech mainstream jazyků. Nebo ano? Taky předpokládám, že se tím nemyslí podpora pro starým slovníkem řečeno „stored procedures“ – např. CouchDB kromě JS podporuje pro views Erlang/Ruby/Python a všechny tyhle views servery jsou už napsané, Nebo ano?)

> 2. lépe podporované (skutečnými firmami, ne skupinkami geeků po 3 lidech),

To je ale nádherný exemplář manipulativního tvrzení! :) Mohl bys to prosím zase upřesnit? Protože jen letmý přehled: CouchDB – pod křídly Apache Foundation, core team > 5 lidí, pracují na něm lidi z IBM, nasazení v Canonical nebo BBC; Tokyo Cabinet – interní storage pro „japonský Facebook“ (mixi); Cassandra – Facebok; SimpleDB – Amazon; Redis – rozsáhlé nasazené v Githubu aj. A to pochopitelně nemluvě o Big Table a Google.

> 3. vhodnější na 95 % aplikací (tedy všude tam, kde není nutné pracovat s terabajtovými objemy dat),

Jak správně píše _několikrát_ Martin, *SQL na aplikace typu „blog“, „e-shop“, „pseudo-twitter“ se používají prostě jen proto, že „je na každém hostingu“, a že jsme na to zvyklí. To, že 95% (číslo také vycucané z prstu :) aplikací používá nějakou abstraktní vrstvu nad SQL (ORM nebo jen nějaký mapper), také svědčí o tom, že je tohle docela diskutabilní tvrzení.

> 4. pokryté mnohem lépe vývojářskými nástroji,

Ano, protože jsou tady XYZ let. To je _jediný_ důvod.

> 5. dostupné na levných hostinzích,

Ano, protože jsou tady XYZ let. To je _jediný_ důvod.

> 6. něco málo v nich napíše i ta největší lama, co si myslí, že databáze = relační.

Nenapíše, většinou bude používat nějakou abstraktní vrstvu nad tou „databází“, resp. SQL. Daleko snadněji bude pracovat třeba s MongoDB, které plní tu roli, jakou relační databáze docela často má (persistent storage a query pro objekty v programovacím jazyce) daleko lépe. Viz ukázky např. v článku http://railstips.org/…o-frameworks.

Ad jazyk: ano, myslím jazyk pro „stored procedures“. A mimo CouchDB jak jsou na tom ostatní k-v storages?

Jestli se nemýlím, tak Apache foundation nenabízí „podporu“. Takovou tu podporu, co si můžeš zaplatit u Oracle, MySQL AB, popřípadě Microsoftu (a kterou nabízejí certifikovaní DBA po celém světě). Imho Facebook taky nenabízí placenou „podporu“. Amazon je na tom dobře, to je pravda (na druhou stranu Amazon nabízí i SQL se stejnou podporou). Github imho taky nenabízí placenou podporu. A co se Big Table týká, tak jsem nikde u Google nabídku placené podpory taky neviděl. Tokio Cabinet má afaik 1 stálého vývojáře, který se mimo to stará snad o další 2 nebo 3 projekty a to všechno při práci. Jestli o TCabinet uslyšíme ještě za 5 let, budu se velice divit.

Myslím, že Martin i ty se v tomto mýlíš. Existují stromová data (kategorie-kategorie-kategorie), existují relační data (např. autoři-články-komentáře) a existují k-v data (seznam zboží na skladě), pak by se jistě našly i jiné typy dat, ale budiž. To, že schema-less k-v storage umožňuje uložit autory, blogposty a komentáře, ještě zdaleka(!) neznamá, že to tak je nejčistší možné řešení. Obdobně by šlo ukládat autory-články-komentáře do XML souboru a není to žádný argument pro opuštění ukládání relačních dat do relační databáze.

Naopak velmi často přechod z SQL na k-v může být (minimálně pocitově) obdobou přechodu z 3. normální formy na 1., tedy věc, ze které každý slušný programátor dostane osypky a začne se poohlížet po zbrani.

To není o tom, na co si kdo zvyknul. To je matematika, povaha dat, povaha přírody. Nějaká data jsou uspořádaná, mají předem danou strukturu a relace, pak jsou tady data, která třeba předem danou strukturu nemají a jsou nenávazná na nic dalšího. To není o zvyku, ale o naprosto racionálním vyhodnocení CO se pokoušíme KAM zapsat. Nehledám tady „nějaké možné“, ale „nejlepší možné“ řešení a to je imho velký rozdíl.

Ad hostingy a nástroje a že jsou tu spoustu let. Každý rok vzniká milion různých databází, milion storage, milion databázových vrstev, milion šablonovacích vrstev, milion frameworků, každý druhý vývojář má pocit, že to udělá „znovu-lépe-radostněji“, proč po těch X letech se několik databází tak dobře drží na trhu? Prostě proto, že mají své místo. Nepochybuju, že nějaké noname k-v storages tu byly už v době COBOLu, jenže už v té době měly navrch uspořádaná strukturovaná data ve vzájemných vztazích … ehm, co mi to jen … aha, relační databáze!

Ad lamy: jako lektor programování, který jezdí po firmách, vím, s čím (minimálně v PHP) vývojáři v Česku pracují. A povětšinou je to ne ORM, ale nějaký bastlobjekt s metodami: connect close query queryToArray queryToRow queryToSingle freeResult do kterého předávají SQLko, které si (v lepším případě) ručně chrání proti SQLi. Nějaký ActiveRecord (který už byl imho DataMapperem docela převálcován) považují často za „žhavou novinku“. Ti největší „profesionálové“ (což jsem doopravdy viděl) generují HTML přímo v databázi.

„Myslím, že Martin i ty se v tomto mýlíš. Existují stromová data (kategorie-kategorie-kategorie), existují relační data (např. autoři-články-komentáře) a existují k-v data (seznam zboží na skladě), pak by se jistě našly i jiné typy dat, ale budiž. (…) To není o tom, na co si kdo zvyknul. To je matematika, povaha dat, povaha přírody. Nějaká data jsou uspořádaná, mají předem danou strukturu a relace, pak jsou tady data, která třeba předem danou strukturu nemají a jsou nenávazná na nic dalšího.“ – není mi jasné, jestli tím polemizuješ se svým vlastním výrokem, že „relačních dat je většina“, nebo jestli se ho tím pokoušíš dokázat. :)

Jestli správně chápu diskuzi, tak pro www programátory je asi nejpřirozenější stromová struktura – jejich prostorem je stránka – layout, která se rozpadá do komponent, kdy každá komponenta může obsahovat další prvky.

Prakticky – strom je obecnější struktura než seznam, takže jakákoliv data lze transformovat do stromu – i když asi jediný prvek, který je skutečně rekurzivní jsou diskuze. U redakčních systémů nejsou pravděpodobné ad-hoc dotazy – co uložím, to chci dostat – pokud možno s co nejmenším úsilím, a co nejrychleji. To NoSQL databáze mohou nabídnout – navíc odpadá ORM.

Ovšem nedovedu si představit např. větší e-shop postavený nad NoSQL databází.

Veeeelice pjekne napisane. Tie skusenosti z lektorovania by mozno stali za clanok. Vyzera to zaujimavo. Best practice tu mame vela. Nejake CodeSmell su ale castokrat uzitocnejsie. Pretoze ludia vedia ze to co robian nemusia robit ako najlepsie sa da, ale v kazdom pripade ich zaujima comu sa vyhnut.

Ale to vůbec není špatný nápad! Co ty na to, Jirko? Agilní metodiky měly úspěch, nechtěl bys napsat něco o praktických zkušenostech z českých firem? :)

Je to bída. Snad všichni dělají něco, co do sebe míchá persistenci, objektové mapování, aplikační logiku, views, validuje se málo, někdy skoro vůbec, ošetřují se data málo, nebo se naopak všechno prožene htmlspecialchar­s(mysql_real_es­cape_string($pro­menna)) bez ohledu na to, kam ta data chtějí uložit/vypsat. Úpravy jsou pak peklo. Kód se duplikuje. Není vyjímkou, že soubory mají tisíce řádků. Že se výstupy chytají do output bufferu a pak přepisují reguláry. Objekty se často používají jen jako skladiště na funkce. O unit testech každý jen „ví“, že jsou „neekonomické a zbytečně zdržují“. Deployment se řeší Total Commanderem. O verzovacích systémech půlka firem asi neslyšela. Prototypování je … cože? a k čemu to jako je? Analýza se nedělá a když už se nějaká dělá, tak když pak klient 10* změní zadání, analýzu se nikdo měnit neobtěžuje. Zdrojáky jsou plné napevno zadaných URL a magických konstant. Štábní kultura neexistuje, každý vývojář to mastí, jak mu to jde z ruky. Když už nějaká štábní kultura existuje, stejně se ve zdrojáku objevují řádky dlouhé 300 znaků. Javascriptové frameworky už (konečně) nevadí, že se natahují. Teď ale děsně vadí natáhnout pár kilo CSS frameworku. Každý si myslí, že si napíš super framework (a že se zázračně vyhne tisícům chyb, které udělali jiní při pokusu o totéž). 3 vnořené foreache jsou košér, ikdyž by to šlo 3 foreachi za sebou. Nikdo nechce používat nové verze PHP, protože ještě nejsou v Debianu (který je zastaralý už v okamžiku, kdy stable verze vyjde – protože je to „bezpečnější“ – říkají hlavně ti, co potřebují bezpečný systém aniž by si sami zabezpečili vlastní aplikaci). Když už někdo chce open source framework, použije na svůj blogísek o 5 stránkách a 1 formuláři desetimegový Zend Framework (a pak zákonitě nadává, že mu to čas nešetří – ba právě naopak). Někdo nechce používat žádný framework, aby mu to náhodou nezpomalilo skript – hlavně u trivální aplikace s návštěvností nulanic na hostingu za 70 korun měsíčně (a pak tam nakonec stejně plácne Drupal, který bez cache musí udělat 300 dotazů, aby zobrazil homepage) – místo toho, aby si nageneroval takovou aplikaci v Cake, Railsech apod. za hodinu a půl. Bezpečnost je důležitá, až když to někdo hackne (navíc za ní klient nezaplatí, protože není vidět). Informační architekturu dělá většinou grafik, v horším případě programátor. Velká část klientů nepozná rozdíl mezi dílem od zkušeného vývojáře a nečím, co 14yrs bastlič MFAček z webtrhu splácá za noc. SEO se řeší až na hotovém webu (nehledě na to, že SEO je pro hodně lidí jen hezké URL, meta description a keywords (k čemu keywords???)). Nevidomí uživatelé a uživatelé zařízení s malým displejem pro některé vývojáře očividně neexistují.

Byl bych sebevrah chtít na něco takového psát článek. Snad každý vývojář by si tam našel něco, za co by „mi to pak v komentářích nandal“. :)

Co by ti nandali? :) Vždyť to je pravda! Maximálně by ti psali, že „to přeci každý ví, že o tom není třeba psát články“, a na to se dá odpovědět: „Čím to tedy je, že když to všichni vědí, tak minimálně v polovině firem se tím neřídí?“ Tam není o čem diskutovat – zato je rozhodně na místě tyhle věci připomínat! Nebo si myslíš, že přijde někdo relevantní a nandá ti, že se mýlíš, že deployment Total Commanderem je ten správný (nebo tak něco)? :) Já bych se rozhodně za nějaké rozepsání přimlouval, a s chutí k tomu ještě pár věcí přihodím…

Yeeeee. Uzasne. My robime pre banky takze s takymito vecami sa nestratavam.
Ja dam tiez nieco :-D
http://freeworld.thc.org/…aintain.html

Kludne napis aj s prikladmi to by bolo fajn.

Nejlepší komentář za hodně dlouho dobu! A svým způsobem velmi k tématu.

Pojďte, třeba Jirku přesvědčíme, že má smysl to rozepsat :)

Já ti ani nevím, jestli to chci ještě jednou číst. Ti, kteří by si to měli přečíst , zamyslet se nad sebou a zařídit se líp, si to stejně nepřečtou, nebo v půlce ohrnou nos, protože jim to tak funguje a kecat jim do toho nikdo přeci nebude.

Těším se, že se jednou ráno probudím a svět bude ideální… ale netěším se na chvíli, kdy zjistím, že ještě sním.

Ja som za. Jirka nandej nam to. Take worst practice skoro ku kazdej vete co je v predchdzajucom prispevku aj s prikladom a pouckou ako sa tomu vyhnut.

No ale co těm firmám poradíte?

Klient takhle sice dostane šílený bastl. ale dostane ho za 15 000,– které ještě zvládne. Když to bude super aplikace od super kvalitního vývojáře, tak by sice byla kvalitní, ale za 100 000,–. Protože kvalitní vývojář něco stojí. To ale klient nepozná, protože on nepozná ani instalaci Wordpressu od speciálního řešení na míru.

Věřte tomu, že i řada firem by ráda dělala super kvalitní aplikace. Jenže když klienti neplatí dostatek peněz, tak nemůžou zaplatit ani kvalitní vývojáře. Vždyť i takové Symbio na „obyčejné“ kšefty (a někdy i ty neobyčejné) najímá studentíky za pár kaček, kteří to nějak zmastí. A nejsou to jen oni, Většina velkých hráčů to tak dělá. Kdybych mohl říct co říct nesmím, tak byste si trhali vlasy i s kořínky, co je všechno možné!

Na druhé straně, díky nízkým cenám je internetová přítomnost firem v ČR neuvěřitelná. Tady má jakous takous prezentaci každý jouda. Například v Německu, Švédsku, Velké Británii (s těmito mám osobní zkušenosti) to tak rozhodně není. Protože tam vývoj stojí řádově více. Tam nemají stránky mnohé velké firmy, instituce, natož nějací živnostníci!

To je pravda pouze zdánlivě. Ve skutečnosti záleží hodně na sebevzdělávání lidí. Dám příklad: protože výborně znám kvalitní framework, jsem schopen naprogramovat klasický CMS s fotogalerií na míru v řádu dní. Tedy rychleji, než bastlič, s tím, že můj kód je čistý, zabezpečení aplikace dokonalé, připravím i testy. Tedy mohu jej dodat ještě levněji, než bastlič (jiná věc je, proč bych to dělal, bavte se tedy spíš o výrobních nákladech). Ta pravá úspora času a nákladu se projeví ovšem tehdy, jakmile klient začne zadání upravovat.

Přitom knowhow je dnes dostupné jako nikdy předtím. Stačí se jen po něm natáhnout. Jenže učení bolí, lidé jsou líní a nedokáží uvažovat s mezikrokem. Raději teď budou dvě hodiny něco bastlit, než týden věnovat sebevzdělání aby později totéž zvládli řádově lépe za hodinu. Naučit se nebo přijmout něco nového není chuť.

Spousta věcí se dá dělat dobře a nezpůsobí to navýšení času. Ve výsledku třeba prototypování (protože se předem ví, co se má skutečně dělat), unit testy (protože pak zkrátí čas následného testování, navíc vede k lepší architektuře a pak k lepší upravitelnosti), použití verzování (založit repozitář je práce na 1 minutu), bezpečnost je dnes velmi dobře řešena ve frameworcích. Neutopit se ve frameworku znamená volit pro projekt odpovídající framework. Je nutné pracovat s know-how zaměstnanců, průběžně je školit a oni pak produktivně vyvíjejí o dva řády kvalitnější kód stejnou rychlostí – jen proto, že ti lidé vědí, kam co patří a ten kód dělí do správných tříd a pak už to „buší světelnou rychlostí“.

Symbio používá framework symfony, které vede k velmi dobrým návykům a spoustu problémů včetně bezpečnosti velice hezky (a produktivně) řeší. Nicméně mám zprávu i od nespokojeného klienta – kdo ví, zda to zrovna nebyla práce od nějakého studentíka. :)

Ad ceny v zahraničí. Je fakt, že třeba UK firma ufinancuje cokoliv (ale opravdu cokoliv, Britové mi v tomhle přijdou až jako ekonomičtí sebevrazi), ale jinak mi zbytek Evropy (mám nějaké – ale velmi omezené – zkušenosti s tímto z UK, Německa a Rakouska) o tolik dražší (nebo spíš ochotnější zaplatit o hodně víc) nepřijde. Ba jsem i potkal situace, kdy ceny byly shodné s ČR.

To me připomíná jednu nejmenovanou firmu :)

Je to všechno jen o pěnězích, nikdo moc (natož malé firmy) nechce investovat (nebo si nemůže dovolit investovat) do věcí, které nejsou vidět (rozuměj, klient je nezaplatí), to je všude, co si budeme nalhávat …

Ad zastaralá verze Debinu: mám zkušenosti jak se stable tak s testing verzí Debinu na serveru a věř Jiří, že používat testing na produkčním serveru si muže dovolit jen člověk, který zaměstnává administrátora serveru na fulltime. Denně nové aktualizace, občas se stane že i s chybou, navíc kvůli závislotem tě to nutí aktualizovat i balíčky, které nechces a podobně … To že se neřeší bezpečnost na straně aplikační logiky je věc z jiného soudku.

Honzo, ta nejmenovaná firma na tom ještě není tak zle. :))

ad Debian: právě proto já teď docela hájím nasazování rpm dister, jako je Centos (kromě jedné naprosto verze Centosu, která má velmi nepovedenou verzi PHP 5.1.6, no ale nad tím jsem se už dostkrát rozčílil při testování pro top.hostingy.cz). Většinou neděláš updaty denně a přitom jsou tam poměrně moderní balíky. Navíc existuji pro Centos snad 2 velmi prověřené a kvalitní repo s novými balíky (PHP 5.3.1 např.)

no musis je delat velmi casto, ne sice dene, ale casto protoze ty baliky jsou testing, tudiz nejsou tak proverene a muze v nich (a byva) dost chyb

Prosím každopádně rozepsat do (nekončícího) seriálu, klidně pod pseudonymem, nebo (se) budu odkazovat na tenhle komentář. Negativní příklady fungují.

Kromě toho co se dělá špatně by mě taky zajímalo, jestli a jak se to dělá jinde dobře a jak (jestli) vyeliminovat ekonomické důvody (výmluvy?) typu „zalevno rychle a špatně, nebo draho pomalu a dobře, co si vyberete?“.

Děkuji Vám za naprosto geniální komentář :). Člověk neví, jestli se má smát, mlátit do hlavy nebo brečet.

> Ad jazyk: ano, myslím jazyk pro „stored procedures“. A mimo CouchDB jak jsou na tom ostatní k-v storages?

Počkat! Já myslel že to _víš_, když to tak rezolutně tvdíš :)

Ty nosql databáze, které trochu znám já, nic jako „stored procedures“ nemají. A ani views Couche nemají striktně vzato nic společného s DB views nebo stored procs. Ten koncept je úplně jiný, „pojďme zaflákat HDD místo CPU“, atd.

MongoDB má queries a indexy, Redis má specifické API. Je to jiný svět. Navíc např. pro oba tyto dva existuje množství wrapperů pro programovací jazyky, takže v Ruby lze i nad Redisem (!) postavit plnohodnotný ActiveRecord-compatible model.

> Jestli se nemýlím, tak Apache foundation nenabízí „podporu“. Takovou tu podporu, co si můžeš zaplatit u Oracle, MySQL AB, popřípadě Microsoftu

Aha, tak prosím napiš raději že ta a ta nosq databáze nemá „placenou podporu“. To je relevantní. Někoho to zajímá, někomu je to jedno. Mně je to třeba úplně a totálně jedno :) Mně zajímá, že mi do pěti minut poradí autor software na IRC kanálu, a když ten spí, tak mi poradí jiný kolega.

> To, že schema-less k-v storage umožňuje uložit autory, blogposty a komentáře, ještě zdaleka(!) neznamá, že to tak je nejčistší možné řešení. Obdobně by šlo ukládat autory-články-komentáře do XML souboru a není to žádný argument pro opuštění ukládání relačních dat do relační databáze.

A není to ani argument pro to, ukládat je do relační databáze. Modelovat vztah článek-komentář můžu pomocí JSON stejně jako pomocí vztahu 1:N. Nebo pomocí chytře napsaného map/reduce v couchi nebo query v redisu, a tak dále.

Nic na světě „od přírody“ nevede k ukládání „ve třetí normální formě“.

> Naopak velmi často přechod z SQL na k-v může být (minimálně pocitově) obdobou přechodu z 3. normální formy na 1., tedy věc, ze které každý slušný programátor dostane osypky a začne se poohlížet po zbrani.

Hmm. Na to tu není prostor. Prakticky každý velký hráč na webu dneska denormalizuje jako o život, kvůli škálování, rychlosti, apod. (Google q=CAP+theorem, q=high+availa­bility, atd)

> To není o tom, na co si kdo zvyknul. To je matematika, povaha dat, povaha přírody. Nějaká data jsou uspořádaná, mají předem danou strukturu a relace, pak jsou tady data, která třeba předem danou strukturu nemají a jsou nenávazná na nic dalšího. To není o zvyku, ale o naprosto racionálním vyhodnocení CO se pokoušíme KAM zapsat. Nehledám tady „nějaké možné“, ale „nejlepší možné“ řešení a to je imho velký rozdíl.

> Ad hostingy a nástroje a že jsou tu spoustu let. … proč po těch X letech se několik databází tak dobře drží na trhu?

Protože zvyk je železná košile. Ale ona ta dominance *SQL prostě skončí, a nejen u velikých hráčů. Když přišly Rails a Django, tak se taky všichni smáli a dneska je to v ASP.NET MVC okopírované i s komentáři nad metodami v controlleru.

> … s čím (minimálně v PHP) vývojáři v Česku pracují. A povětšinou je to ne ORM, ale nějaký bastlobjekt s metodami: connect close query queryToArray queryToRow queryToSingle …

Právě. Řečeno nyní ve spěchu bez obalu: mapují si nesmysly z MySQL na nějakou nativní strukturu jazyka, aby s tím mohli inteligentně pracovat. V MongoDB by jim bylo líp. Třeba na to někdy taky přijdou.

Ad otázka na ty jazyky. To je jen taková manipulativní otázka… :))

Ad „můžu uložit tak nebo jinak“ je zase vzdálene tomu jak to můžu udělat nejčistěji. Obdobně JSON je jen zamaskovaná 1. normální forma, 1:N prostě patří do 2 tabulek, jinak to není „nejčistší možné“ řešení. A dokud nemám v té databázi joinovat terabajt dat s jiným terabajtem dat, NIC mě nepřesvědčí, že mám záměrně dělat zprasené řešení, když znám čisté řešení.

A že můžu napsat nějaký správný reduce – stejně tak můžu napsat xpath dotaz na XMLkem, které si uložím do MySQL a přitom to neznamená, že je to ten nejlepší možný způsob. :)

„Nic na světě od přírody nevede k ukládání ve třetí normální formě.“ – záleží na úrovni rozlišení. Můžeš mít objekt zeměkoule, kterou serializuješ a uložíš na disk. Nebo můžeš mít objekt člověk, těch uložíš 7 miliard. Nebo můžeš mít objekt buňka, kterých uložíš 2 na padesátou (to jen tak cucám z prstu). Relační databáze vychází z relační algebry, mají v matematice oporu a dají se mapovat na skutečné věci. Článek má omezený počet atributů o daném typu, komentář má omezený počet atributů o daných typech, uživatel jakbysmet, služební vozidlo také, budova také, nákupní košík také, objednávka také, poptávka z webu také, statistika přístupů také. Těch ustálených dat je spousta, kdežto potřeba ukládat „jednou 3 atributy, podruhé 200 tisíc, nikdy stejné typy“ je v přírodě jako šafránu.

Velcí hráči denormalizují jen proto, že spravují objemy dat, které si běžný smrtelník neumí představit. To je problém, s kterým se tady v Česku potká možná tak seznam a pár obdobných. Ti ostatní jsou na mezi, kdy můžou škálovat pohodlně s Oracle, které je na takovou zátěž připravené.

Ad „zvyk je železná košile“ – ale proč se stal zvykem? Když v té době už existovaly obdoby k-v (ostatně formát proměnných v lispu nebo APL by se mnohem snáz serializoval do k-v storage). Proč se SQL stalo standardem v době, kdy žádná železná košile nebyla?

Djangu a Railsům jsem nikdy v životě neviděl nikoho se posmívat. Ty ano?

Ad to mapování – právěže nemapují. Oni si naprosto zbytečně udělají objekt nad obyčejným voláním funkcí mysql_connect, mysql_query, mysql_close…, to nemá s objektovým programováním nic společného. Je to jen taková fasáda, na kterou když se zeptám, proč ji vlastně mají, nikdo neumí odpovědět.

Jirko, čistota řešení je jen vkusu. Ten máme každý jiný…

> A že můžu napsat nějaký správný reduce – stejně tak můžu napsat xpath dotaz na XMLkem, které si uložím do MySQL a …

Takový XPath ale bude technicky i filosoficky vzato úplně jiného kalibru než např. map/reduce (+index, +btree, +incremental index build) v couchi.

> Můžeš mít objekt zeměkoule, kterou …

Omyl je v tom, že o tohle tolik nejde. Modelování jde prostě dělat různě a vlastně na tom ani moc nezáleží. Skutečný rozdíl je v reportování a ad hoc dotazech. Viz několik komentářů Pavla Stěhuleho zde v diskusi.

> … běžný smrtelník neumí představ … tady v Česku potká možná tak seznam …

Nene, stačí pracovat s netriviálním objemem záznamů v řádu jednotek miliónů a už to začne docela vadit, pokud se smíříme s představou, že „kupte si Oracle“ není řešení pro každého.

> Djangu a Railsům jsem nikdy v životě neviděl nikoho se posmívat. Ty ano

No jasně, dnes a denně :) Pravda, za ty roky se to docela zlepšilo. A mimochodem, ten úplně _hlavní_ argument „proti“ je právě ten „je málo podpory na hostingu“. Ty české hostingy by měly dostat nějaký grant z investičního fondu EU na rozvoj konkurenceschop­nosti, jak to tak vypadá. To je vyložená žába na prameni :)

Ať se koukám sebelíp, žádné komentáře v kódu třídy Controller nevidím :) http://aspnet.codeplex.com/…t/view/23011#…

Tam ne, přímo v controlleru, GET /books/1 etc, viz např. http://nerddinner.codeplex.com/…t/view/23425?…

Aha tohleto :) jedna z nejhorších věcí, kterou rychle mažu už v globální šabloně VisualStudia. Osobně zastávám názor, že komntář je zastaralej, jen co ho dopíšeme, obvzlášt komentář s Routou je věc která zastará za chvilku. Navíc, když mám aplikaci, která má routy lokalizované do víc jazyků, tak to strácí smysl úplně… :) Možná si někdo v Redmondu myslel, že to je dobrej nápad, já to s ním ale nesdílím…

Jasně, „zkopírovat i s komentářema“, to byl jen takový obrat, něco jako „sežrat i s chlupama“ .)

Nic na světě „od přírody“ nevede k ukládání „ve třetí normální formě“.

Souhlasím s tím, že záleží na detailu. Příklad – knihovna – pokud budeš řešit domácí knihovnu, pak 3NF je něco, k čemu by se mohl snadno dostat i neškolený programátor. Pokud začneš hypotetickou absolutní knihovnou – tak pravděpodobně začneš mnohem dřív řešit hierarchii – a dost možná, že skončíš u nerelační db.

Souhlasím s tím, že 3NF není samozřejmá – lidé jsou zvyklí „škatulkovat“. Souhlasím i s tím, že s denormalizovaná data můžeš načítat o dost rychleji – pokud se ovšem pohybuješ po jedné vytyčené koleji. S NF mám mnohem větší možnosti dotazování, analyzování dat – což se bere i jako jedna z základních funkcí db.

Možná by stačilo konstatovat, že pro redakční a podobné systémy je databáze nepotřebná – úplně postačuje persistentní cache. Myslím si, že to je to, na čem tu možná trochu ztroskotává diskuze – lidé, kteří pracují s DB si představují pod pojmem databáze trochu něco jiného – a umí s databázemi jiné kousky, než programátoři redakčních systémů.

K tomu poslednímu odstavci: Mějme na paměti, že Zdroják je magazín o WEBOVÝCH technologiích, a ty „Opravdové Databáze“ (jak tu někteří komentátoři občas použijí příklad s bankovními aplikacemi v Javě) jsou na webu kuriozitou, nebo přinejlepším výraznou menšinou. Jejich schopnosti práce s DB nikdo neumenšuje ani neupírá, jen – pro web je to většinou „kanón na vrabce“ a priority webové aplikace jsou, přese všechny společné základní řemeslné poučky, přeci jen trochu někde jinde než priority bankovní aplikace. Takže: Nechme „trochu jiné představy o DB“ těm, kdo je mít mohou, a vraťme se zpátky na web. :)

Trochu mi nesedí termín „webové aplikace“ – v kontextu o kterém se bavíme. Z hlediska správy dat mi přijde docela zásadní si všímat rozdílů mezi redakčními systémy, eshopy a intranety. Vyjma redakčních systémů si nedovedu představit systém, který by se obešel bez klasické relační databáze. Přijde mi, že účelově klamete tvrzením „webová aplikace = redakční systém“.

Ono „webové aplikace“ je vůbec trochu divná kategorie, když se bavíme o ukládání dat – to je jako zohledňovat, jestli ta aplikace má GUI napsané pomocí GTK nebo Qt, na tom přece (z hlediska dat) nezáleží. Takže souhlas – daleko víc záleží na smyslu té aplikace (redakční systém, účetnictví, skladiště informací…) než jestli to má webové rozhraní (protože to má dneska kde co).

Webová aplikace je to, co je navrženo jako aplikace primárně ovládaná přes web. Toto implikuje některé další vlastnosti, jako například orientaci na přístup více uživatelů najednou ve stejném čase pomocí nestavového protokolu HTTP, z čehož vyplývají zase určité požadavky a omezení, které mají v důsledku vliv na formu ukládání dat. Je s tímto vymezením nějaký problém? Nesouhlasíš s tím? Myslíš si, že je jedno, jestli je aplikace určena primárně pro desktop (~1 uživatel) nebo pro web a že to nijak neovlivní formu ukládání dat?

(Ponechme stranou všechny mezistupně, jako „vnitropodnikové IS“ a spol.)

„Myslíš si, že je jedno, jestli je aplikace určena primárně pro desktop (~1 uživatel)“

To jsem nikde nenapsal :-)

Myslel jsem tím klient/server aplikace – s těmi pracuje taky víc než jeden člověk zároveň. Jak se bude lišit třeba účetnictví podle toho, jestli má webové rozhraní nebo tlustého klienta. Resp. jak se bude lišit struktura jeho databáze (ať už jakékoli)? A bezestavovost HTTP protokolu se snad vyřeší někde nahoře a na datovou vrstvu její následky přece nedopadnou, ne?

„(Ponechme stranou všechny mezistupně, jako ‚vnitropodnikové IS‘ a spol.)“
Jo, už asi vím, jak to myslíš.

Přijde mi, že účelově klamete (pokud se tedy chcete bavit na této úrovni) zjednodušováním – Facebook, Google Maps, GMail, LinkedIn, Digg, Websnapr, Photoshop.com, Twitter, Bit.ly, Youtube nebo zmiňovaný FriendFeed patří přesně kam? Eshop, intranet nebo redakční systém?

můj výčet není určitě úplný. U řady aplikací nenajdete jasné hrany – viz např. Google Wave – aplikace z Vašeho výčtu rozhodně nejsou ani eshopem a nejsou ani intranetem. Odpovím otázkou – na kolik je Google Maps typickou www aplikací (bez ohledu na to, že používá speciální ro db)? Pro mne jsou některé z Vašeho výčtu – jednoduché, nebo složitější redakční systémy – vložíte obsah, který v té či oné formě prezentujete.

Většina toho, co na webu je, a to včetně eshopových frontendů (a naprosté většiny intranetů), je ve stylu „uložím data – prezentuju data“. Vaší terminologií to jsou tedy „redakční systémy“ – a můžeme tam klidně zahrnout vše, co jsem zmínil. Čímž se vracíme k té rovnici „(moje) webová aplikace == (váš) redakční systém“, kterou jste nazval „účelovým klamáním“.

Většina toho, co na webu je, a to včetně eshopových frontendů (a naprosté většiny intranetů)k, je ve stylu „uložím data – prezentuju data“. Vaší terminologií to jsou tedy „redakční systémy“ – a můžeme tam klidně zahrnout vše, co jsem zmínil. Čímž se vracíme k té rovnici „(noje) webová aplikace == (váš) redakční systém“, kterou jste nazval „klamáním“.

A co je ako kanon na vrabce? SQL databaza? Na com ze to povacsinou bezia web aplikacie? Ja som myslel ze nad MySQL co je SQL relacna databaza. Co mi uslo?

Ad Kanón na vrabce: „Myslím si, že to je to, na čem tu možná trochu ztroskotává diskuze – lidé, kteří pracují s DB si představují pod pojmem databáze trochu něco jiného – a umí s databázemi jiné kousky, než programátoři redakčních systémů.“ TYHLE databáze jsou kanón na vrabce.

Fakt som asi mimo ale:
- Pouzivame objectovo-relacny mapovaci nastroj (hibernate/JPA)
- DEV na MySQL/PostgreSQL
- Test na PostgreSQL
- Rutina PostgreSQL (a asi bude Oracle)
- Prave teraz vytvarame specializovany redakcny system na objednavku
- Sam som vytvaral a robil architekta na XML databazach, Objektovych databazach, Messagingu, LDAPoch, …

No a teraz, vsade som za tym videl alebo to fungovalo na relacnym modelom. Myslite ze co pouzivaju nativne objektove databazy (LDAPy, XML databazy)? Bud boli postavene nad SQL databazou alebo vnutri bol pouzity relacny model. Mam dlhorocne skusenosti (aj ked teraz nepouzivam) s ODBMS Versant. Ten sa da programovat na viacerych vrstvach kde najvyssia je objektova a najnizsia je asi nieco na styl k-v. No a cuduj sa svet druha zospodu je nieco ala SQL pre potreby reportigu, dotazovania, … .

Kde su vyhody pouzitia NoSQL? Podla mna je to krok spat a to je to co sa tu snazim zistit, co prehliadam ze nevidim tu vyhodu?

Ten Versant bol super a patri ku spicke objektovych databaz. Dnes ho ale kombinacia objektovo mapovaci framework + relacna databaza porazi v comkolvek. Relacna databaza + SQL tu bola a zostane veeelmi dlho. Mozno s nejakymi XML, ci objektovymi nadstavbami ale je to nieco ako chytrejsi filesystem. Nic viac nic menej.

Sorry aj za niektore ine prispevky ak boli trochu off topic ale ludia sa to rozpisuju o takych veciach ze sa mi oci krizia.

zajimalo by me, kolik je vam let.

Ja jsem takovy hype uz zazil nekolikrat. Jako C programator jsem se take ptal, jake vyhody jsou v tom c++ a objektove orientovanem pristupu, co jsem asi prehledl. Dnes, po 20 letech Vam muzu odpovedet, ze jsem se nemylil. Programy se nestaly lepsi, jistesji a projekty nejsou levnejsi. Ani jedno, co se slibovalo nenastalo. Ale presto jsem musel v dalsich zamestnanich rikat, jak v te c++ valim, abych mohl prezit.

Podobne to bylo pred 10 lety. Perl. Byl jsem vazenym programatorem, protoze jsem si precetl tu syntaxi a u 5-teho jazyka clovek zjisti, ze je vsechno stejne. Dnes je perl pro smich. Ani to nikde nerikam, co vsechno jsem v tom napsal. Java je in a python ci jak se ostatni vsechno jmenuje. Zrovna tak dotnet.

Mohu vas ujistit, neprehledl jste nic. Protoze se na tu problematiku divate pouze z technicke stranky. Budete se ale divit, az se Vas u pristich projektu budou ptat, jestli ovladate NoSQL. A ja vam garantuji, ze to zakaznikovi slibite a po podepsani kontraktu se stavite v knihkupectvi a koupite si o tom NoSQL nejakou knizku.

> Ja jsem takovy hype uz zazil nekolikrat.

Tak to ano, vela a hlavne na GUI. Co sa tyka ‚database hype‘ ja si pamatam hlavne objektove a XML databazy a to tlacili velke komercne firmy. Vysledok – z mojho pohladu nic. Vylepsili sa nadstavby nad relacne bazy a kara ide dalej. Vtipne mi iba prislo ze to fakt boli nadstavby. Toto NoSQL je akysi suteren databaz. Nieco co by mozno malo byt v jadre databazy nie nad nou. Niekde som uz pisal ako to mal vyriesene napr Veritas kde tento k-v level bol pod SQL level a tam to aj patri.

> Jako C programator jsem se take ptal, jake vyhody jsou v tom c++

Myslim ze OOP dekompozicia nieco priniesla. Kniznice, riadenie pamate, …

> Podobne to bylo pred 10 lety. Perl.

Toto obdobie ma preskocilo. Presiel som od REXX, Ruby (BTW Ruby je hrozne stary jazyk), Perl, Python velmi rychlo a dlhodobo som sa venoval Jave. Uz od prvych verzii nakolko som vychovany Basicom, dBase, FoxBase, C/C++, SQL, Ingres 4GL.

> u pristich projektu budou ptat, jestli ovladate NoSQL

V prvom prispevku som dufam dostatocne objasnil preco sa ma to dufam nikto nikdy neopyta. Naviac to dokazem dobre technicky vyvratit. Ale uz sa ma pytali aj na .Net, a ten je myslim niekde inde ako NoSQL, a odolal som :-D. Myslim ze tak ako nevymreli COBOL programatori tak uz asi aj ja umriem nad Javou.

… přece jen poněkud staršího data …

jasný, nevěřte ničemu, čemu je přes třicet (teda čtyřicet, ale to tam nepasuje)

btw. moc se mi líbí, jak se v tomhle threadu žongluje se slovem relační