Přejít k navigační liště

Zdroják » Různé » MySQL v roli neschémové databáze

MySQL v roli neschémové databáze

Články Různé

Neschémové databáze (pro které se vžilo označení „NoSQL“) jsou stále populárnější. 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. Pojďme se podívat na zajímavý příklad netradičního využití MySQL ve službě FriendFeed.

Článek je volným překladem článku Breta Taylora, vydaného pod CC-BY licencí 27.2.2009 na autorově blogu.

Na úvod

Ve FriendFeedu používáme pro ukládání veškerých dat MySQL. Naše databáze rostla zároveň s počtem uživatelů. V současnosti je v databázi přes 250 milionů záznamů („současnost“ je únor 2009, pozn. překl.) a spousta dalších dat, od komentářů a příznaků „líbí se mi“ až po seznamy přátel.

Během růstu databáze jsme se museli vypořádat s problémy škálovatelnosti, které se objevily spolu s růstem. Udělali jsme to, co se dělává: Použili jsme čtení ze slave databází a memcached pro zvýšení výkonu při čtení, a rozdělili jsme databázi (v originále „database sharding“ – technika, při níž jsou záznamy umisťovány do různých fyzických úložišť podle nějakého předem stanoveného kritéria – pozn. překl.) pro zvýšení výkonu při zápisu. Ale škálování existujících funkcí tak, aby stačily zvýšenému přenosu dat, se ukázalo být tím menším problémem v porovnání s přidáváním nových funkcí.

Konkrétněji: změnit strukturu tabulky nebo přidat indexy do databáze s více než 10–20 miliony řádků zaměstná databázi naplno po dobu několika hodin v kuse. Odstranění starých indexů zabere neméně času, a pokud je neodstraníte, sníží to výkon celého stroje, protože databáze bude dál číst a zapisovat do nepoužitých bloků při každém INSERTu, a bude si tak odsouvat z paměti to potřebné. Existují určité postupy operací, které můžete dělat, abyste se těmto problémům vyhnuli (jako nastavit nový index nejprve na slave stroji a pak prohodit slave a master), ale tyto procedury jsou velmi náročné a náchylné k chybám. 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í.

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) (psali jsme o ní na Zdrojáku – pozn. překl.). 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. 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.

Po jistých úvahách jsme se rozhodli implementovat „neschémové“ úložiště nad MySQL namísto vytvoření kompletního nového úložiště. V tomto článku se pokusím popsat nejvýraznější rysy tohoto systému. Zajímá nás, jak se s podobnými problémy vypořádávají jiné velké servery, a doufáme, že některé z našich úvah mohou být užitečné ostatním vývojářům.

Pokud vás naopak zajímá to, jak využít správně všech výhod, které MySQL nabízí, a pokud se chcete naučit správně používat MySQL jako relační databázi, přijďte na školení Akademie Root.cz s tématem Návrh a používání MySQL databáze, kde se dozvíte vše potřebné od návrhu až po samotné využití MySQL ve vašich projektech. Školení je vhodné jak pro důkladné seznámení se základy databází, tak pro využití MySQL u náročnějších projektů.

Přehled

Naše úložiště ukládá neschémové seznamy atributů (jako JSON objekty nebo Pythonské slovníky). Jediná vyžadovaná součást uloženého záznamu je identifikátor, který tvoří šestnáctibajtový UUID. Zbytek záznamu je z hlediska úložiště nezajímavý. Můžeme tedy snadno změnit „schéma“ prostým uložením nových atributů. (V originále „properties“, překlad „vlastnost“ by nebyl vhodný, proto budu používat „atributy“ – pozn. překl.)

Uložená data indexujeme pomocí indexových záznamů, uložených v oddělených MySQL tabulkách. Pokud chceme indexovat tři atributy v každém záznamu, budeme mít tři MySQL tabulky, pro každý indexovaný atribut jednu. Když budeme chtít přestat užívat index, prostě přestaneme do této tabulky zapisovat. Tabulku pak můžeme smazat. Když potřebujeme nový index, uděláme pro něj novou MySQL tabulku a spustíme asynchronní proces, který index na pozadí naplní, aniž by to mělo vliv na „živou“ službu.

Nakonec jsme skončili s větším počtem tabulek, než jsme měli předtím, ale přidávání a odstraňování indexů je teď snadné. Máme velmi dobře optimalizovaný proces, který vytváří nové indexy (zvaný „Čistič“). Ten dokáže rychle naplnit indexové tabulky, aniž by přitom „zboural“ celý web. Můžeme přidávat nové atributy a indexovat je v řádu dnů, nikoli v řádu týdnů, a nemusíme kvůli tomu prohazovat MySQL master a slave nebo dělat jiné děsivé akce.

Detaily

Naše entity jsou v MySQL uloženy v tabulce, která vypadá nějak takto:

CREATE TABLE entities (
    added_id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
    id BINARY(16) NOT NULL,
    updated TIMESTAMP NOT NULL,
    body MEDIUMBLOB,
    UNIQUE KEY (id),
    KEY (updated)
) ENGINE=InnoDB;

Sloupec „ added_id“ je tu proto, že InnoDB ukládá řádky fyzicky v pořadí podle primárního klíče. Primární klíč s AUTO_INCREMENT  zajistí, že nově přidané záznamy jsou na disk zapisovány sekvenčně za starší záznamy, což napomáhá zápisu i čtení (nové záznamy bývají čteny mnohem častěji než starší záznamy, čemuž napomáhá i to, že stránky FriendFeed jsou řazeny v obráceném chronologickém pořadí). Těla záznamů jsou ukládána jako pythonské slovníky, serializované (pickled) a komprimované pomocí zlib.

Indexy jsou ukládány v oddělených tabulkách (v originále sharded – pozn. překl.). Když vytváříme nový index, vytvoříme novou tabulku, která obsahuje atributy, jež chceme indexovat. Kupříkladu typický záznam (entita) ve FriendFeedu může vypadat takto: 

{
    "id": "71f0c4d2291844cca2df6f486e96e37c",
    "user_id": "f48b0440ca0c4f66991c4d5f6a078eaf",
    "feed_id": "f48b0440ca0c4f66991c4d5f6a078eaf",
    "title": "We just launched a new backend system for FriendFeed!",
    "link": "http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c",
    "published": 1235697046,
    "updated": 1235697046,
}

Chceme indexovat atribut „ user_id“ v těchto záznamech, abychom mohli zobrazit stránku všech záznamů daného uživatele. Naše indexová tabulka bude tedy vypadat nějak takto:

CREATE TABLE index_user_id (
    user_id BINARY(16) NOT NULL,
    entity_id BINARY(16) NOT NULL UNIQUE,
    PRIMARY KEY (user_id, entity_id)
) ENGINE=InnoDB;

Naše datové úložiště udržuje indexy automaticky, ve své režii. Pokud chceme se záznamy pracovat, můžeme použít nějaký takový kód (v Pythonu):

user_id_index = friendfeed.datastore.Index(
    table="index_user_id", properties=["user_id"], shard_on="user_id")
datastore = friendfeed.datastore.DataStore(
    mysql_shards=["127.0.0.1:3306", "127.0.0.1:3307"],
    indexes=[user_id_index])

new_entity = {
    "id": binascii.a2b_hex("71f0c4d2291844cca2df6f486e96e37c"),
    "user_id": binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"),
    "feed_id": binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"),
    "title": u"We just launched a new backend system for FriendFeed!",
    "link": u"http://friendfeed.com/e/71f0c4d2-2918-44cc-a2df-6f486e96e37c",
    "published": 1235697046,
    "updated": 1235697046,
}

datastore.put(new_entity)

entity = datastore.get(binascii.a2b_hex("71f0c4d2291844cca2df6f486e96e37c"))
entity = user_id_index.get_all(datastore, user_id=binascii.a2b_hex("f48b0440ca0c4f66991c4d5f6a078eaf"))

Třída Index hledá atribut user_id ve všech záznamech a automaticky spravuje index v tabulce index_user_id. Protože je naše databáze dělená, udává argument shard_on klíč, podle kterého bude rozhodnuto o konkrétním umístění (zde podle čísla  user_id).

Můžete položit dotaz na index pomocí instance této třídy (viz user_id_index.get_all výše). Kód úložiště udělá potřebný „join“ mezi tabulkou „ index_user_id“ a tabulkou entit v Pythonu, a to tak, že nejprve požádá o seznam ID záznamů ze všech tabulek index_user_id ze všech dílčích databází, a pak vyzvedne tyto záznamy z tabulky entities.

Pokud chceme přidat další index, například indexovat odkazy (atribut link), vytvoříme opět novou tabulku:

CREATE TABLE index_link (
    link VARCHAR(735) NOT NULL,
    entity_id BINARY(16) NOT NULL UNIQUE,
    PRIMARY KEY (link, entity_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Změníme inicializační kód datového úložiště tak, aby zohlednil nový index:

user_id_index = friendfeed.datastore.Index(
    table="index_user_id", properties=["user_id"], shard_on="user_id")
link_index = friendfeed.datastore.Index(
    table="index_link", properties=["link"], shard_on="link")

datastore = friendfeed.datastore.DataStore(

    mysql_shards=["127.0.0.1:3306", "127.0.0.1:3307"],
    indexes=[user_id_index, link_index])

Nakonec asynchronně naplníme index (tedy za normálního provozu) pomocí:

./rundatastorecleaner.py --index=index_link

Konzistence a atomicita

Konzistence je v situaci, kdy je databáze je rozdělena na více strojů a indexy pro entity mohou být uloženy na různých oddílech, často na jiných než entita samotná, docela problém. Co když zkolabuje proces předtím, než jsou zapsány všechny záznamy do všech indexových tabulek?

Vytvořit transakční protokol se stalo výzvou pro ty nejambicióznější vývojáře FriendFeedu, ale chtěli jsme zároveň udržet systém tak jednoduchý jak jen to je možné. Rozhodli jsme se porušit některá pravidla konzistence, jako například:

  • Indexy nemusí vždy odrážet aktuální stav záznamů
  • Směrodatný je obsah dat v tabulce entities

V důsledku toho zapisujeme nové záznamy do databáze v těchto krocích:

  1. Zapíšeme záznam do tabulky „ entities“ a využíváme přitom vlastností ACID, které nabízí InnoDB
  2. Zapíšeme indexy do všech indexových tabulek ve všech dílech databáze.

Když hledáme informace v indexu, tak víme, že nemusí být přesné (například mohou obsahovat staré hodnoty atributů, pokud při update neproběhl korektně krok 2). Abychom se ujistili, že nevracíme neplatná data, používáme indexy jen jako vodítko k tomu, abychom zjistili, jaké záznamy načíst, ale patřičné filtry aplikujeme znovu na načtené záznamy; nemůžeme totiž důvěřovat indexům jako autoritativnímu zdroji informací. Tedy:

  1. Přečteme entity_id ze všech tabulek podle dotazu
  2. Načteme záznamy z tabulky entities podle získaných ID
  3. Vyfiltrujeme (v Pythonu) všechny entity, u nichž hodnoty atributů neodpovídají podmínkám v dotazu.

Abychom se ujistili, že v indexech něco nebude chybět napořád a že nesrovnalosti budou opraveny, prochází proces „Čistič“, který jsem zmiňoval v předchozím textu, neustále tabulkou entit, zapisuje chybějící indexy a čistí staré a neplatné záznamy. Při práci postupuje od posledních změněných záznamů, takže nesrovnalosti v indexech jsou opraveny v praxi velmi rychle (během pár sekund).

Výkon

Optimalizovali jsme naše indexy a výsledkem jsme příjemně překvapeni. Výkon stoupl a latence je stabilní. Se systémem je navíc velmi snadné pracovat. (originálním článku jsou grafy, ukazující zlepšení stability výkonu, v kontextu tohoto článku na Zdrojáku nebyly nezbytné – pozn. překl.)

O autorovi: Autor textu, Bret Taylor, je spoluzakladatel služby FriendFeed a její bývalý CEO, nyní (po odkoupení FriendFeedu Facebookem) pracuje ve Facebooku jako produktový ředitel.

Poznámka překladatele

Na výše uvedený článek jsem narazil náhodou, když jsem hledal informace o rozumném, snadno použitelném a netradičním ORM systému pro PHP, který by fungoval jako persistentní úložiště objektů. Zvažoval jsem migraci k nějaké „čisté NoSQL“ databázi, ale problém je s tím, že NoSQL databáze nepatří do standardní nabídky webhostingů. Výše uvedený článek mi připadal jako velmi inspirativní, právě pro vývojáře, kteří by rádi zkusili přechod k NoSQL a využili přitom široce dostupné, známé a relativně spolehlivé MySQL databáze. Navíc přináší pohled autora opravdu velkého webu, což je zkušenost pro většinu vývojářů v ČR neznámá. Proto jsem se rozhodl článek přeložit, i když je už téměř rok starý, a nabídnout čtenářům Zdrojáku.

Komentáře

Subscribe
Upozornit na
guest
155 Komentářů
Nejstarší
Nejnovější Most Voted
Inline Feedbacks
View all comments
Patrik Votoček

Nebyly by nějáké další zdroje k tomuto tématu na které jsi při pátrání narazil?

keff

Díky za výborný nález (a překlad který nerve uši :)), tohle je nejlepší case study pro NoSQL co jsem zatím viděl!

Btw, zajímalo by mě jak se v takových případech řeší verzování – tedy, když si s deseti miliony uživatelů vzpomenu, že by měl mít uživatel navíc třeba profilové foto, a jen foreach user { get, unserialize, pridej_foto, serialize, put } trvá třeba týden.

Asi bych přidal každé entitě typ a verzi, a pro každý typ a verzi entity bych měl připravenou funkci, která by se zavolala při prvním přístupu k entitě a upgradovala by jí na aktuální verzi:


for (i=entity.version; i < actual_versions[entity.type]; i++) {

  upgrade_function_name = "upgrade_{entity.type}_{entity_version}";

  if (function_exists(upgrade_function_name)) {

    entity = call(upgrade_function_name, entity);

  }

}

Co na to čtenáři?

PS: vkládání kódu sucks – odsazoval jsem pomocí nbsp;, uvnitř tagu code jsem musel odřádkovávat s BR, a menšítko jsem musel zapsat jako entitu… to se dá snad i v Drupalu naklikat za 20 minut víc user friendly :((. A když už jsme u toho, kód by měl být o hodně menším písmem…

keff

… a teď mě napadá že to celé musí být v transakci (jinak se nám může entita upgradovat vícekrát – a pravděpodobně bude, stačí když netrpělivý uživatel refreshne stránku dřív než doupgradujeme, nebo se třeba zavolá API call). Takže buď potřebujeme aby naše hrdá NoUglySQL pokorně vzala z sql transakce (begin; get; upgrade; put; commit;), nebo musíme použít princip ala JavaSpaces, kde get objekt z db vyndavá, a i po čtení ho musíme zase putem vrátit zpět (a doufat že mezitím nespadneme :)).

Jakub Vrána

Vtip je v tom, že se záznamy vůbec modifikovat nemusí. Z databáze se prostě načte beztypový slovník. Když s tímto slovníkem potom pracuji, tak jen musím počítat s tím, že tam některé klíče prostě nebudou.

keff

V tom případě bych nechtěl být ten, kdo píše logiku aplikace – vážně myslíte, že je lepší, aby v sobě měla každá funkce pracující s entitami (třeba i 3 roky starými) víc ifů a switchů, než vlastní byznys logiky?

Ne že bych chtěl vypadat jako zapšklý strongly typed konzervativec, ale mě přijde lepší vědět že entita user má ta a ta pole, než psát funkci která bude rozumně fungovat s jakoukoliv verzí uživatele která se používala během celého života aplikace. A tohle není žádný umělý problém, nastává všade kde se neupravují data společně s programem (a zrovna ho náhodou taky řeším, proto mě zajímají názory ostatních :)).

Jakub Vrána

Ale ona to vůbec nemusí řešit každá funkce. Stačí, když to vyřeší nějaký centrální prvek (zde asi přímo datastore při získávání dat).

Ped

Ja bych rekl ze vetsina funkci ktere pracuji s entitou pracuji prave s konkretnim atributem (dvema-trema), takze mnozstvi ifu nebude az tak velke, mozna 1–2 na zacatku funkce, jestli se da vubec aplikovat na danou entitu.

T.j. rozsirovani entit podle mne nezpusobi v zdrojaku takovy chaos (vetsina puvodnich funkci nove atributy do ted nepotrebovala, tak je nejspis nebude potrebovat ani po jejich pridani) jako treba nejaka zmena atributu aby v novejsich entitach obsahovali trochu jine data a pod.

A mam takovy pocit ze se porad bavime na urovni „modelu“, t.j. casti ktera se da docela dobre pokryt unit testy a refactoring/roz­sireni je pak relativne stejne drahe po celou dobu vyvoje bez ohledu na aktualni slozitost entity. Proste to tak od oka napisete po novem, pustite testy a zjistite jestli jste se trefili nebo tomu neco chybi. Vetsinou pak failed testy napovi co jste od oka nedomyslel, je to vlastne takova vedomostni databaze ktere se muzete velmi rychle ptat na „jednoduche“ programatorske problemy typu „kolik funkci se mi rozbije kdyz tohle v entite zmenim“ a pod… (ktere vypadaji jednoduse, ale pri slozitejsi entite a vetsim mnozstvi funkci uz jejich reseni v hlave trva nejakou dobu .. rozhodne vic nez natukani nejakeho prototypu zmeny a pusteni testu)

Inkvizitor

No tak v některých jazycích se to dá vyřešit elegantněji. Např. v Pythonu se na slovníku použije operace get(), která má implicitně pro neexistující klíče hodnotu None a případně se tam dá nějaká hodnota explicitní (škoda, že Python v takových případech neumožňuje jednoduše líné vyhodnocování funkcí jako některé funkcionální jazyky – Haskell, OCaml apod. – to by byla teprve paráda).

Víc by mě trápila jiná věc – pokud ten model není triviální, dojde člověk nakonec často k tomu, že si začne vytvářet vlastní mechanismus indexů apod., zkrátka se selektováním řádků (v horším případě i s joiny) mu databáze nebude umět pomoci. To se časem může strašlivě vymstit a trpí výkon celé aplikace. Časem zjistíš, že Ti zabere spoustu času optimalizace a simulace relační databáze nad NoSQL. Samozřejmě, pokud člověk ví, kde takovou jednoduchou databázi použít, může se to hodit. Obecně jsem ale spíš pro opatrnost.

Michal Krause

Pokud jde o vkládání kódu, stačí jej uzavřít do

<pre><code>kód</co­de></pre>

případně použít Texy zápis:

/—code
kód

Jakub Vrána

Což o to, řešení je to chytré a evidentně funkční. Ale přijde mi škoda, že kvůli jednomu problému (blokující ALTER) do značné míry rezignovali na schopnosti MySQL a emulují si je sami (místo indexů vytváří tabulky a místo změny struktury modifikují BLOB).

Možná, že kdyby stejné úsilí napřeli do toho napsat neblokující ALTER (tedy patch pro MySQL a hlavně InnoDB), tak by výsledek byl stejný a mohli by z toho těžit všichni. Tedy i ti, kteří MySQL využívají jako relační databázi.

aprilchild

Napsat neblokujici ALTER pro velkou databazi je asi jako napsat novy databazovy stroj. To myslim jako odpoved staci. Do toho se nepousteli ani sakra chytri kluci z FF (jeden z nich, Paul Buchheit napsal GMail, to jen kdyby nejakeho stouru napadlo pochybovat, ze jsou chytrejsi nez on).

Jakub Vrána

Facebook to dokázal. Publikovali nástroj pro změnu tabulky, na kterou se nemusí čekat.

Jan Kodera

On ten ALTER má problém v tom, že MySQL jako řádkově orientovaná DB prostě trvá na tom, že každý sloupec musí být v řádku naznačen (buď NULL nebo nějaká default hodnota). A prolézt celý soubor chvilku trvá, zvlášť když tam jsou věci jako BLOB, či TEXT u kterých není jasné jak jsou dlouhé, takže se musí projít a pak se posunout. Práce by to byla strašlivá.

Oni přece úplně nerezignovali na relační schopnosti. Oni je používají (viz index je v relaci s entitou apod.). Spíše se jedná o rezignaci na 3 normálovou formu. Data jsou denormalizována a tudíž není třeba tolik JOINů (vlastně žádné). Jak se píše v článku, tento přístup pak přenáší část práce na aplikaci (poslední filtraci dat).

Lukas

V každé diskusi, kde se popisuje nějaké řešení, se vždy objeví alespoň jeden člověk, který napíše, že to měli (mohli) udělat úplně jinak, jednodušeji a smysluplněji…

A to je spatne? Myslim ze ne, nekdy se stane, ze takovy komentar ma vetsi hodnotu nez cely clanek.

aprilchild

pro zajemce, temer klasikou se stal post R. Jonese

„Anti-RDBMS: A list of distributed key-value stores“. Jedna se o starsi text, s nejnovejsi diskuzi. Neni to sice uplny seznam (kdo ho ma..), ale jako uvod do problematiky a vlastniho studia se hodi.

http://www.metabrew.com/…alue-stores/

Martin Soušek

Zdá se mi, že znovuobjevili dávno známou věc.

Stačí si přečíst pár patentů Google, vyzkoušet AppEngine a zjistíte, že tohle bylo dávno vynalezeno. Ani není potřeba ta MySQL.

S každým to bohužel zamává, protože tyto škálovatelné přístupy staví na hlavu všechno, co jsme se doposud učili a považovali za jediné možné.

Palo

Alebo si aj precitajte o problemoch z AppEngine a ake jednoduche tieto technologie su. Postavit na tom mail system ktory obsahuje tak 4 polozky ale hlavne to musi byt rychle je uplne nieco ine ako vytvorit ERP system.
Ked to potrebujete aj tak tam musite strcit nejaku vrstvu ktora vytvori vyssi interface. Takze v podstate nic nebrani tomu vytvorit rovnaku strukturu pod standardnym SQL systemom. Je to iba otazka vytvorenia noveho DB systemu ktory by bol od zaciatku navrhnuty ako distribuovany a skalovatelny. Tieto vlastnosti sa do existujucich SQL databaz pridavali az dodatocne.

X

Budu si to muset přečíst ještě jednou. Napoprvé to na mě působí jenom jako optimalizovaná db architektura a takto si nepředstavuji NoS­QL.

Trochu se mi nezdá, když mluvíte o tabulce s ~25 (250) miliony záznamy a reindexace trvá několik hodin. Nějaké informace o datové větě, či velikosti tabulky v bytech by nebyly?

PM

„tabulce s ~25 (250) miliony záznamy a reindexace trvá několik hodin“ – to není vůbec nereálné.

fos4

InnoDB + char + utf8 nezarucuje pevnou delku. Pouze tu minimalni.

fos4

Nepsal, šlo pouze o doplnění.

PS: o jaky typ slo ? zajimalo by mne to.

fos4

Treba by enum vysel lepe nez tinyint a char. Nevim jak je to s rychlosti budovani indexu u intu a enumu ale tusim ze char a varchar budou pomalejsi.

Ivan

A neni hlavne hrani? Ty kluci do toho museli investovat dost casu(tzn. i penez).
Kdyby si za ty penize poridili nejaky rozumny zelezo s vice jak 150GB RAM, tak mohli cely MySQL nahradit necim co ma vsechna data v RAMce a jednou za cas je odlije na disk. Oni vlastne zadnou DB nepotrebuji jedna giganticka hash tabulka by jim stacila na vsechno.

MyOwnClone

Fajn clanek, diky za nej!

Jiří Knesl

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>

krteQ

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

backup

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

Jiří Knesl

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ří Knesl

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.

Palo

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

Palo

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.

Palo

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.

Petr

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.

František Kučera

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.

backup

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

Jiří Kosek

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.

Palo

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.

Palo

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.

Jiří Kosek

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?…

Jakub Vrána

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.

Jiří Kosek

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.

František Kučera

„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…

František Kučera

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

Karel Minařík

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]

okbob

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

okbob

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.

Almad

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.

František Kučera

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…

Palo

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

František Kučera

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.

Palo

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

Lukáš Konarovský

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.

Palo

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.

František Kučera

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

František Kučera

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

HolyHop

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

Palo

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.

mike

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

Palo

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.

koles

mozna s vyjimkou tech, co to uz zkusili…

krteQ

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

Jan Kodera

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?

backup

…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 …

logik

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.

logik

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

Palo

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

Mard

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

A

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

Aneb OffTopic flame.

Karel Minařík

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.

Jiří Knesl

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.

okbob

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

Palo

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.

Jiří Knesl

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

Palo

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.

David Grudl

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

Jaroslav Moravec

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.

Palo

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.

Martin Soušek

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!

David Grudl

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

Jiří Knesl

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.

Jens.cz

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.

Jiří Knesl

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

Jens.cz

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

Langi

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?“.

Vojta

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

Karel Minařík

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

Jiří Knesl

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.

Aleš Roubíček

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

Karel Minařík

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

Aleš Roubíček

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

Karel Minařík

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

Aleš Roubíček

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…

Karel Minařík

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

okbob

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

okbob

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

František Kučera

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

František Kučera

„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íš.

okbob

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.

Palo

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?

Palo

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.

backup

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.

Palo

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

jos

… 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í

krteQ

Je vyrazne rychlejsi na innodb pluginu (neplest se standardnim innodb), protoze se uz nemusi rebuildovat cela tabulka. Problemem zustavaji unikatni a primarni klice.

Trochu nechapu, ze jim prepinani master/slave pri udrzbe dela problemy, ale asi maji opravdu svizny vyvoj :)

Lukas

Jeden NoSql systém tady máme už 15 let – je to LDAP, vytvořený pro případy, kdy záleží na rychlosti čtení, k zápisům dochází velmi málo a dočasné nekonzistence mezi kopiemi je přijatelná.
Na jednom projektu na kterém jsem pracoval jsme s LDAPem měli problémy – pracovalo se s ním velmi těžce, přínosy byly zanedbatelné oproti omezením.

Jsem rád, že se o NoSql začalo mluvit, že vývojáři přestali vnímat sql jako jedinou volbu. Znám případ, kdy vývojář indexoval několik terabyte textové informace pomocí MySql:). Nicméně, tohle byl speciální případ, 95% procent projektů nejspíš noSql nepotřebuje a naopak ocení výhody ACIDu, abstrakce, řešení relací. Za tyhle skvělé features zaplatí určitou cenu, ale většinou ta cena bude zanedbatelná oproti reimplementaci byť i podmnožiny featur které SQL nabízí.

Palo

No ale tie velkeeee LDAPy behaju prave nad SQL databazami.

Lukas

jj, ja vim. Je to paradox. Ale API maji oproti ostrihane na uroven NoSql.

Michal Blaha

Přelétl jsem zrychla všechny a některé kvalitní komentáře i podrobněji.
Nebudu přikládat pod kotlík „SQL“x“k-v db“.

Jen pár poznámek, které zapadly v diskuzi a stoji za to je připomenout:
1) článek je case study. Popis řešení konkrétního problému v konkrétním prostředí.

2) Pánové ve FF byli v situaci, kdy narazili na realné limity relační DB (ne technologické, ale praktické) a museli v omezeném čase, s omezenými prostředky (kapacita) a danným know-how prokázat výrazné zlepšení.
A to u projektu, kde je datová struktura velmi a často modifikována (což si přiznejme není pro relační DB a navázaný kód situace ideální).

(doporučuji jako jiný příklad historii změn architektury backendu Twitteru. Tuším 5 změn za 3 roky)

3) Omezené knowhow je poměrně zásadní omezení. Pokud má team letité zkušenosti s MySQL, tak týdenní školení Oracle na 5× výkonnější HW je k ničemu. Chybí ty zkušenosti, které se dají rychle pouze koupit (člověk). A teď mi na světě ukaže, kolik lidí má špičkovou znalost Oracle, na prudce roztoucí bázi dat s neodhadnutelnou zátěží (rostoucí spíše exponenciálně než lineárně).

Tato case study je podle mne krásnou ukázkou dobré racionální a pragmatické úvahy, jak dosáhnou „přijatelného řešení“ v omezeném prostoru.
A současně důkazem, že toto je _jedna z cest_ kudy se dá vydat a není to cesta slepá. To stojí za ocenění.

Můžeme diskutovat zda zůstat u MySQL bylo lepší než přejít na Oracle či cokoliv dalšího. Můžeme se dohadovat, jak moc strukturovaná jsou data kolem nás či kolem měsíce. Ale je to jen hezká intelektuální rozcvička.
Pravda se ukáže pouze na bojišti. A to má k teorii hodně daleko.

David Grudl

Vždy je zajímavé si přečíst, jak hackují technologie tam, kde mají natolik vytížené stroje, že si to ani neumíme představit, ale bylo by chybou z toho vyvozovat obecné závěry platné pro „nás dole.“

Ale když už téma NoSQL bylo nakousnuto… V IT platí, že život si komplikujeme sami.

Je fajn naučit se uvažovat i mimo mantinely, které jsme si sami uměle vytvořili. Např. si uvědomit, že neplatí, že pro ukládání dat jsou SQL databáze a že 4. normálová forma je nejčistší způsob organizace dat, nýbrž že SQL databáze jsou jen jedním z možných úložišť a normálová forma platí hlavně v nich. Denormalizace, používání nerelačních úložišť atd – to jsou zcela korektní záležitosti.

„SQL fuj, NoSQL huj“ je jen hloupá móda, jak už módy bývají, protože jen jinak nastavuje mantinely.

Uvažování v mantinelech a podléhání módním výstřelkům způsobilo, že svět není schopen uspokojivě vymyslet, jak zkombinovat objekty programovacích jazyků s relacemi databází. Ba co víc, už v případě prostého eshopu s velkou variabilitou zboží může i zkušený architekt tonout. Přitom stačí na věc nahlédnout s větším odstupem nebo bez módních serepatiček a řešení se ukáže jako triviální.

…nojo, ale my v IT si rádi život komplikujeme sami :-) Borcům z FriendFeedu velké plus za schopnost hledat netradiční cesty!

Palo

Je tu ale niekolko ale. Bavit sa o problemoch normalnej formy nema zmysel. Ta je v poriadku a ktorakolvek sa da zachytit v SQL databaze (aky bordel si tam urobite je vasa vec). Vyssie normalne formy prinasaju iba vyssie usporiadanie a poriadok ale nikto vas nenuti ich pouzivat.
NoSql databazy vyzera ze maju iba technologicku vyhodu proti niektorym SQL databazam. Tieto nevyhody mozu byt v buducnosti v SQL databazach odstranene (napriklad pridanie nullable stlpca by nemuselo trvat nic).
Co je vtipne ze aj na tu NoSQL databazu vyuzivaju naspodu SQL databazu takze si vlastne sami dobrovolne orezavaju funkcionalitu ktoru maju.
Ja som sa naucil ze SQL a relacny model je akysi dobry zaklad vsetkeho. Pouzivali sme aj nativne XML databazy, aj nativne objektove databazy. Kazda ma nieco do seba ale vsetko sa to da realizovat nad beznou relacnou SQL databazou. Pre mna je SQL databaza nieco ako chytrejsi file to je vsetko.
Ja pouzivam Javu cez Hibernate/JPA a pracujem s Java objektami. Ked je treba napise sa nativne SQL query alebo nativny SQL update. Nevidim ziadny hlbsi vyznam v tom ochudobnovat sa o SQL na nizsej vrstve. Co by som tym akoze ziskal?

Bob

No jo, kdyz se pouzije dostatecne velke nasili, lze pomoci kladiva i sroubecek zatlouct. Jestli by ale nebylo lepsi pouzit primo vhodny nastroj, at uz ve forme poradneho designu, takze nemusim kazdou chvili delat alter table, poradne sql databaze, takze alter table netrva par hodin nebo vhodne ne-sql databaze.

C

Zatlouct ano, ale ne zašroubovat. :-)

Almad

Aplikace typu FF se vyviji neustale, tam je alter table nutnost bez ohledu na kvalitu designu.

Almad

Ja jen dopredu reagoval na protiargument „takov CMS firmy se udela jednou a pak se na ni rok nehrabne“.

IMO neni spatne obcas vymezit, kdy se jedna klasicky o startup a vyvijenou sluzbu a kdy se doda jednorazove neco na zakazku (jasne, i do toho se nakonec hrabe, ale podminky jsou proste jine).

František Kučera

Asi by to ale chtělo rozlišovat „weby“ a „webové aplikace“. U aplikací platí to, co píšeš, ale u těch webů se moc nového vymyslet nedá – tam se mění design (prezentační vrstva → tudíž všechno pod tím může zůstat) a přidává obsah (články, fotky…) změny struktur jsou ale minimální – např. web, který má prezentovat firmu, může stát na prakticky stejných strukturách jako před deseti lety, jen se mu dá moderní design a aktuální data. Podobné to bude u webů zaměřených na obsah – jejich „core byznys“ je psát pěkné články, třeba cestopisy, to je důvod, proč tam lidi chodí. Takže tam se taky nebude měnit struktura moc často – hlavně bude přibývat obsah a občas se modernizuje vzhled.

Almad

Ano, mluvil jsem o aplikacích. Jsem přesvědčen, pro 99% „webu“ není důvod nenasadit nějaké krabicové řešení a tudíž nemá moc smysl to řešit (prostě se použije takové datové úložiště, které to podporuje…pro většinu těch webů je to stejně – specielně v ČR – jedno).

Vojta

Zdravím všechny. Tento článek i pár podobných jsem si přečetl, ale nemyslím si, že je toto správná cesta. Relační databáze je dělaná jako relační databáze, je pro tento účel navržená, vytvořená, optimalizovaná a ozkoušená. Ukládat v ní samozřejmě lze všelicos, ale proč pro toto „všelicos“ používat právě relační databázi? Není jednodušší naimplementovat nový (vlastní) databázový stroj určený k pro ukládání takových dat?

Probíhala tu i obecnější diskuse o ORM. ORM je mapování objektů na relační model, takže už z principu je to takový „bastl“, který míchá dva různé pohledy na tutéž věc. Proto jsou s tím (a vždycky budou) problémy. Když je tedy potřeba používat objektový model, proč nepoužít objektovou databázi? Nebylo by moudřejší věnovat více energie zde?

Ano, je to tady kvůli kompatibilitě. 90% všech systémů se nevytváří od nuly, ale modifikuje. Proto tu s námi relační databáze ještě chvíli budou. Z toho důvodu je také nemoudré v tomto čase u nějaké firmy zavádět navržené NoSQL řešení, protože je nové a za pár let může někdo přijít na to, že je to blbost, a bude se snažit „rozházeným“ datům znovu dát nějaký řád a smysl.

Nebráním se pokrokovým myšlenkám a experimentům – právě naopak, sám si rád hraju. Proto přeji hodně štěstí při práci s konceptem NoSQL databáze, ale podle mě tato bublina brzy splaskne. Toto je pouze můj skromný názor :).

František Kučera

„Není jednodušší naimplementovat nový (vlastní) databázový stroj určený k pro ukládání takových dat?“

Já jsem tedy vlastní databázový stroj nikdy nepsal, ale řekl bych, že jednodušší to nebude. Správnější/čistější možná, ale jednodušší určitě ne. (A v rámci běžného projektu je něco takového nereálné). Důležité jsou výsledky, ne řeči – takže pokud jim to takhle funguje a aspoň rok fungovat bude, tak bych to považoval za dobré řešení (i když mi zrovna nesedí). Prostě vyřešili projekt, splnili úkol a to se počítá – my se tu jen hádáme v diskusi :-)

„takže už z principu je to takový „bastl“, který míchá dva různé pohledy na tutéž věc.“

A jak je nemíchat, když tu relační databázi prostě musíš mít? Nepřevádět záznamy na objekty, ale rovnou z DB generovat HTML? To je pěkná prasárna. Nebo na objekty rezignovat a záznamy skrz naši aplikaci proplouvat jen jako pole textů a čísel? To mi přijde hrozně nepohodlné a vedoucí k chybám. Nebo generovat v databázi XML (třeba taková PostgreSQL to docela hezky umí) a pak ho prohnat přes XSLT do (X)HTML. Jo, to by asi šlo.

Většinou se s tím ale člověk musí nějak poprat – na jedné straně má objekty, na druhé relace – pak se použije buď ORM, jakožto obecný framwork, kterému předhodíme akorát mapovací metadata (jaké tabulky na jaké třídy), nebo ORM nepoužijeme a napíšeme si to mapování ručně jako nějakou DAO vrstvu.

Sebastian

Zdravíško,
hezký článek, ale asi jsem jej moc nepochopil… :(
Každopádně, neni tohle pomalé? Přeci jenom, hledáme třebas Field uživatele Franty, takže projdem tabulku index_user_id ze které dostaneme entity_id, pak musíme nahládnou do tabulky entities a získat tělo (slovník) entitity na základě indexu; ze kterého stejně jestě musíme získat data, která nás zajímají..?
Proč prosě nejde použít tabulku?
CREATE TABLE entities (
id INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
feed_id BINARY(16) NOT NULL,
user_id BINARY(16) NOT NULL,
title VARCHAR(64) NOT NULL,
link TINYTEXT NOT NULL,
posted TIMESTAMP NOT NULL,
updated TIMESTAMP NOT NULL,
UNIQUE KEY (feed_id),
KEY (updated)
) ENGINE=InnoDB;
Teď jak to píšu, tak si začínám uvědomovat normální pravidla, takže „jen“ proto?

Martin Kavalec

Rozhořela se tu debata o tom jestli je noSQL hype nebo něco užitečného, jestli je používání relačních databází jen zvyk a zaběhaná praxe.
Vždycky se hodí se zamyslet, jestli není lepší něco udělat jinak, přijít s novým a neotřelým řešením a taky se stojí za to zamyslet, oc co tím přijdeme.

Relační databáze tady nejsou několik desítek let jen ze zvyku, je pro to dobrý důvod. To, že realitu „rozbíjíme“ a „natloukáme“ do relačního schématu má velkou výhodu v tom, že se ta „rozbitá“ realita pak dá poskládat i jinak, můžeme se na takto uložená data podívat několikerým způsobem a relační databáze jsou desítky let optimalizovány na to, aby data uměly poskládat tak, jak si zrovna vzpomeneme.

U jednodušších aplikací je možné, že to nepotřebujeme, že aplikace bude pracovat s daty stále stejným způsobem, že si ušetříme práci s modelováním a ukládáním do relací, s ORM… na webu se asi najde dost příkladů. Ale je potřeba se třikrát zamyslet, jestli se to někdy nevymstí.

Provozujeme loyalitní program, členové si mohou na webu objednávat dárky, ty je třeba objednat od dodavatelů a rozeslat členům programu. Pokud objednávky uložíme do relačního modelu, stačí jeden select s group by, aby bylo jasné kolik čeho musíme objednat. Jenže když si weboví programátoři usnadní práci a celou objednávku uloží do databáze jako objekt přes php_serialize, máme o zábavu postaráno… e-shop může být ukázkový příklad, kde se NoSQL moc nehodí, ale tohle se fakt stalo…

Enum a statická analýza kódu

Mám jednu univerzální radu pro začínající programátorty. V učení sice neexistují rychlé zkratky, ovšem tuhle radu můžete snadno začít používat a zrychlit tak tempo učení. Tou tajemnou ingrediencí je statická analýza kódu. Ukážeme si to na příkladu enum.