Javascript - map / reduce / filter

V době, kdy jsem se poprvé setkal s javascriptem, nic nenaznačovalo tomu, že by se jednou z tohoto jazyka stalo to, co prožíváme nyní.
Psát o tom, že je to jazyk, který se vrací jako bumerang a v současné době zažívá své znovuzrození, je stejně zbytečné, jako to, že je to jazyk, který má asi nejsvětlejší budoucnost ze všech.

Díky bohu, že jsme se postupně dostali přes různé slepé uličky či uzavřeli jQuery, které splnilo svou historickou povinnost a odešlo do věčných lovišť. Již dávno jsou pryč časy, kdy většina vývojářů k javascriptu přistupovalo způsobem: google -> stackoverflow -> copy & paste.

Díky nové specifikaci (ES5 a ES6), jsme schopni k tomuto jazyku již přistupovat mnohem přímočařeji.

Dnešní ukázka se bude týkat práce s polem. V ukázce je použit typescript.

1. Představte si, že máte uživatele, který má následující vlastnosti:

interface User {
    readonly id: number;
    readonly firstName: string;
    readonly lastName: string;
    readonly roles: string[];
    readonly countOfClicks: number;
}

2. Nyní si vytvoříme pole uživatelů

const users: User[] = [
    {id: 1, firstName: 'Ales', lastName: 'Dostal', roles: ['admin', 'operator', 'manager'], countOfClicks: 32},
    {id: 2, firstName: 'Petr', lastName: 'Vomacka', roles: ['operator', 'manager'], countOfClicks: 43},
    {id: 3, firstName: 'Martin', lastName: 'Novak', roles: ['manager'], countOfClicks: 0},
    {id: 4, firstName: 'Petr', lastName: 'Novotny', roles: ['operator'], countOfClicks: 13},
    {id: 5, firstName: 'Jan', lastName: 'Novak', roles: ['manager', 'superuser'], countOfClicks: 31},
    {id: 6, firstName: 'Petr', lastName: 'Sulek', roles: ['manager', 'superuser'], countOfClicks: 18},
];

Úkol 1: Celkový počet kliků

Prvním zadáním je celkový počet kliků, všech uživatelů.
Pokud bychom nepoužívali ES5 a arrow functions, tak by zápis vypadal následovně:

let countAll = 0;
for (let i = 0; i < users.length; i++) {
    countAll += users[i].countOfClicks;
}
console.log('countAll: ', countAll);

V případě využití ES5 a arrow functions, lze dané zadání přepsat následovně:

const countAll = users.reduce((result, user) => (result + user.countOfClicks), 0);
console.log('countAll: ', countAll);

Výsledek:

countAll: 137

Docela rozdíl, že? Pojdmě se podívat na další možnosti, které již budou využívat pouze ES5 a arrow functions. Nechceme přeci psát zastaralým stylem :)

Úkol 2: Průměrný počet kliků

Dalším úkolem je, znát půmerný počet všech kliků, přes všechny uživatele. Pokud bychom nevycházeli s předchozího výsledku, který bychom jen vydělili celkovým počtem uživatelů, je možné i tento úkol zapsat pomocí funkce reduce:

const average = users.reduce((result, user, index, array) => {
    result += user.countOfClicks;
    if (index === array.length - 1) {
        return result / array.length;
    }
    return result;
}, 0);
console.log('average: ', average);

Výsledek:

average: 22.833333333333332

Úkol 3: Najdi všechny uživatele s jménem Petr

Výsledkem tohoto úkolu by mělo být pole uživatelů, kteří splňují podmínku, že jméno uživatele je Petr.

const petrUsers = users.filter((f) => f.firstName === 'Petr');
console.log('petrUsers: ', petrUsers);

Výsledek:

petrUsers:  [ { id: 2,
    firstName: 'Petr',
    lastName: 'Vomacka',
    roles: [ 'operator', 'manager' ],
    countOfClicks: 43 },
  { id: 4,
    firstName: 'Petr',
    lastName: 'Novotny',
    roles: [ 'operator' ],
    countOfClicks: 13 },
  { id: 6,
    firstName: 'Petr',
    lastName: 'Sulek',
    roles: [ 'manager', 'superuser' ],
    countOfClicks: 18 } ]

Úkol 4: Pole ID uživatelů

Vysledkem úkolu je pole ID uživatelů

const ids = users.map((user) => (user.id));
console.log('ids: ', ids);

Výsledek:

ids: [ 1, 2, 3, 4, 5, 6 ]

Úkol 5: Unikátní pole rolí

Výsledkem bude pole rolí, kde se žádná z rolí nebude opakovat:

const roles = users.reduce((result, user) => {
    result.push(...user.roles.filter((f) => result.indexOf(f) === -1));
    return result;
}, []);
console.log('roles: ', roles);

Výsledek:

roles: ['admin', 'operator', 'manager', 'superuser']

Úkol 6: Pole jmen a počet výskytů

Výsledkem bude pole jmen a počet výskytů v poli uživatelů.

const uniqueFirstNameCount = users.reduce((result, user) => {
    result[user.firstName] = (result[user.firstName] || 0) + 1;
    return result;
}, []);
console.log('uniqueFirstNameCount: ', uniqueFirstNameCount);

Výsledek:

uniqueFirstNameCount: [Ales: 1, Petr: 3, Martin: 1, Jan: 1]

Závěr

Znalost využívání funkcí jako je map, reduce, filter, find či sort je jedna z klíčových věcí, kterou by programátor měl znát.
Díky tomu, že javascript je jazyk, který lze dnes využívat i na serveru, tak díky znalosti funkcí pro pole je možné tuto znalost aplikovat, například pro mongodb.
Pokud by někdo našel optimálnější způsob zápisu, daných úkolů, nechť se o ně podělí v komentáři.

Jak by se firmy neměly chovat k programátorům? Druhé pokračování...

Vzhledem k tomu, že jsem se zavázal k pokračování článku "Jak by se firmy neměly chovat k programátorům?" Tak tady je.

Příklad 5: Open space je skvělý

Ne, open space je největší zlo, které nikdy nemělo vzniknout. Existují tři důvody, proč ho většina firem používá.

První a jediný pravdivý důvod je to, že je to ekonomicky výhodnější, postavit jednu velkou kancelář, kam posadím 30 lidí. Přeci jen, málokterá firma má peníze na rozhazování.

Druhým důvodem je to, že šéf může lépe kontrolovat, co jeho zaměstnanci dělají a zda jsou vlastně na svém místě. K tomuto se snad dá odpovědět pouze tak, že ano, sice je vidět, zda jste v práci a máte otevřen ten správný program, který má na Vašem monitoru svítit, ale už to nic neříká o tom, zda skutečně pracujete a zda pracujete produktivně.

V jedné firmě jsem zažil skutečné peklo. Nejenom, že jsem byl kontrolován snad i na počet kliků myší, ale navíc jsem „získal“ to nejhorší místo z celé té velké stodoly. To znamená, že za den kolem mě prošlo tak tisíc lidí a to mi způsobovalo to, že jsem se skutečně nebyl schopen soustředit na svou práci. Navíc jsem se občas chtěl podívat i na soukromé věci. Ale otevřít si facebook? Sakra, působil bych jako flákač…

Třetím důvodem je to, že lidé v open space mezi sebou více komunikují. Mám pro Vás smutnou zprávu. Nekomunikují. Lidé si vytváří sociální vazby úplně jinak, než jak by si přáli jejich šéfové. Zažil jsem mnohokrát situaci, kdy lidé, kteří seděli v open space, cca 2 metry od sebe, tak si raději napsali po chatu, protože vůči sobě seděli zády a bylo příliš složité se otočit a mluvit. Navíc by to rušilo ostatní.

Open space je proti lidské přirozenosti. Lidským instinktem je totiž to, že si každý z nás chce vytvořit své „útočiště“. Tedy vlastní pracovní prostor, který nebude nikým narušován. Lidé si chtějí dát na svůj stůl svůj hrníček, fotku rodiny, samolepku svého týmu, apod. Je to pro nás přirozené. Snažíme si vytvořit prostor, který nám bude příjemný a nebude pro nás tak stresující. Bohatě stačí to, že po nás šéf chce výsledky a vyhrožuje snížením mzdy J

Spoustu let jsem pracoval v oddělené kanceláři, kde seděli další tři lidé. Bylo to to nejefektivnější období mého života, které jsem zažil.

Příklad 6: Šéf je jako Steve Jobs

Psát o tom, kdo byl Steve Jobs je asi zbytečné. Vizionář, který…. bla bla bla. Osobně nemám nic proti Jobsovi, sám používám Apple produkty.

Co je ovšem naprosto špatně? Představte si situaci, že pracujete ve firmě, kde dojde na nejhorší. Šéf dostal od manželky k Vánocům novou knihu s názvem: „Buď jako Steve Jobs“. Po vánočních svátcích, naplněn novými poznatky se pokusí je ihned využít. Já jsem šéf, já tomu rozumím nejlépe a já jsem vizionář. A tak začne poučovat ostatní a řídit věci, kterým nerozumí.

Programátor se v té chvíli dostane do svízelné situace. Jak mám šéfovi vysvětlit, že jeho nápad je úplná kravina? Jeho vize je sice dokonalý produkt, ale díky svým neznalostem jen způsobí zničení toho, co do té doby bylo dobře.

Opět něco z praxe. Měl jsem šéfa, který mi dával najevo, že všemu rozumí lépe než já a že ví, jak by věci měly být. Ale já jeho vizi nesdílel. A v tomto případě platí jedno pravidlo: „Boj se svým šéfem nikdy nevyhrajete“. Firmu jsem proto opustil a šel si dál svou cestou… 

Příklad 7: Manažeři rozumí svému byznysu lépe než programátoři

Většina firem má striktně rozděleny své role. Programátor tvoří software a manažer určuje, jak bude software vypadat a co má umět. On přeci mnohem lépe ví, co uživatelé chtějí a co je dneska „cool“.

Možná se zdá, že tady je vše v pořádku. Bohužel tomu tak není.

Zkusím trochu odbočit. Víte, co mají společného firmy jako: Google, Facebook či Microsoft? Ano, správně! Jsou to IT firmy. Ale také společnosti, které byly založeny programátory. Ať už lepšími či horšími, ale byli to programátoři.

Co z toho vyplývá?

Otázka pro manažery. Kdy naposledy jste se ptali svých programátorů na byznys? Co by udělali jinak a nemyslím tím technicky.

Otázka pro programátory. Kdy naposledy se Vás šéfové ptali na byznys? Co byste udělali jinak a nemyslím tím technicky.

Mnoho firem by se možná divilo, s čím by jejich programátoři přišli. Pokud banda manažerů, bez špetky technických znalostí, navrhuje, co by měl software umět a jak by měl vypadat, je to vždy špatně.

A zase trochu praxe. V jedné firmě jsem zažil to, že jsem dostával přesné zadání, které jsem měl implementovat. Tady je svět asi v pořádku, až na to, že to často byly nesmysly, které bych svým uživatelům skutečně nechtěl nabízet. Funkčnosti stály dost peněz a do dnes jsem přesvědčen, že to nemohlo být výhodné ani pro jednu stranu.

Pokračování příště….

Jak by se firmy neměly chovat k programátorům?

Každý, kdo pracuje v IT oboru, se jistě již setkal s různými „geniálními nápady“, od kterých si firma slibovala zlepšení produktivity či snížení nákladů. Ať už je to zavedení agilních principů, striktní kontrola práce či zavedení nové a skvělé metodiky, o které si „šéf“ přečetl včera na internetu. Jsou z toho skutečně tak nadšení i samotní vývojáři? A bude nový nápad fungovat?

K napsání tohoto článku mě navedly různé programátorské diskuze, kde si lidé stěžovali na firmu, kde pracují.

Příklady, které zde uvedu, jsou z reálné praxe. Ať už jsem je zažil jako řadový programátor, či jako šéf týmu.

I když je poptávka po programátorech tak vysoká, že Vás headhunteři nahánějí i ve chvílích, kdy o to opravdu nestojíte, tak i přes to je mnoho lidí, kteří se bojí opustit svoje současné zaměstnání.

Čeho se nejčastěji bojíme? Je to samozřejmě nejistota, kterou si často omlouváme větami jako: „Tady mám své pohodlí, co když to jinde mít nebudu?“ nebo „I když mě to v práci štve a nebaví, tak mě alespoň nechávají na pokoji“. Jenže jak dlouho toto člověk může skutečně vydržet? Jednou ten den přijde, kdy si člověk řekne: „A dost.“.

Takže čím "pomáhají" firmy k tomu, aby nás do takové fáze dostali?

Příklad 1: Šachové figurky

Setkal jsem se s firmou, která postoj ke svým programátorům měla následující: „Franta půjde dělat systém ABC a Pepa půjde do týmu k Honzovi“. Současně s tím se ale nikdo neptal těch lidí, zda o to stojí. Zda je nová pozice bude bavit. Zda Franta skutečně chce dělat na systému ABC a zda Pepa vidí Honzu jako dobrého šéfa. A ve chvíli, kdy vznikly první problémy s odchodem zaměstnanců, tak to šéfové připočítávali naprosto nesmyslným předpokladům, jako je například plat. Raději se ptejte svých lidí, zda chtějí být přesunuty tak, jak jste si zaevidovali v excelu.

Příklad 2: Agilní metodiky nás zachrání

Mnoho firem je dnes obětí toho, že se nechaly nalákat na to, že SCRUM vyřeší všechny jejich problémy s dodávkami či kvalitou.

Pracoval jsem v několika společnostech, kde se pod pojmem SCRUM mínilo: „Máme standup a k tomu pevný termín a scope.“ Takže jedeme ve SCRUMu a očekáváme lepší zítřky. Finále je, že se nezmění naprosto nic. To je jako kdybyste našroubovali na Formuli 1 kolo od traktoru. Bude to skutečně lepší?

Věřte, že nám programátorům nepřináší naprosto nic Vaše vize, o kterých už dopředu víme, že nebudou fungovat. Klidně přiznejte, že jedeme čistý „waterfall“ a raději tomu přizpůsobte zbytek. Není to žádná ostuda, když firma jede v čistém vodopádu. Ostuda spíš je, když se to firma stydí přiznat. Pokud Vám business nedovolí mít volný termín či scope, nehrajte si na SCRUM. Programátorům se uleví.

Příklad 3: Striktní kontrola

Mnoho lidí se domnívá, že čím víc budu kontrolovat své podřízené, tím budou pracovat efektivněji. Je to ten největší omyl, se kterým se můžete setkat.

Vzpomínám si na své první zaměstnaní jako programátora. Dostal jsem se do firmy, která měla pravidlo, že musím každý den odevzdávat worklog, který měl být co nejdetailnější. Tedy nejlépe každou hodinu sepisovat, co jsem skutečně udělal.

Jakožto junior, který neměl ani tušení, jak to chodí, tak jsem se snažil poctivě vyplňovat každou hodinu. Přesně podle skutečnosti. Výsledkem bylo to, že jsem dostal vynadáno, jak to, že mi chybí 1 hodina a odpracoval jsem jen 7 hodin, místo nařízených osmi.

Poté jsem pochopil, co dělám špatně. Málo v tom worklogu lžu. Od té chvíle jsem si začal vymýšlet a psát tam vše, co mě jen napadlo, i když to nebyla pravda. Výsledek se dostavil. Byl jsem pochválen. Tabulka byla vyplněna a já měl tedy splněno.

Co z toho vyplývá? Jestli chcete, aby Vám programátoři nelhali, přestaňte je buzerovat něčím, co sami ani nečtete. Zajímá Vás jen konečný součet hodin, že? OK! Pracoval jsem 8 hodin na systému ABC.

V pozdějších dobách jsem se dostal do jiné firmy jako šéf týmu. Dostal jsem za úkol, že všichni mí podřízení musí vyplňovat worklog, který později budu prezentovat. Díky mému poučení z dřívějších dob, jsem zaujal jasný postoj. Vyplňme jen to nutné minimum, víc stejně nikoho nezajímá. Vás to nebude obtěžovat, nebudete muset lhát a mě přidělávat starosti. Stejně tím, že řekneme, kolik času jsme nad danou činností strávili, nijak nezrychlíme naše pracovní nasazení. Nicméně může to pomoci k pozdějšímu návrhu pracností, což může být výhoda i pro nás.

Příklad 4: Franta je nejlepší vývojář, takže bude šéf

Toto platí obecně. To, že je někdo nejlepší ve svém oboru, ještě neznamená, že bude dobrým šéfem.

Za svůj profesní život jsem prošel desítkami pohovorů. Vzpomínám si, že jsem zažil pohovor s budoucím šéfem, který mě zkoušel z různých příkladů. Už od první chvíle mi bylo jasné, že práci nepřijmu, nicméně jsem si řekl, že to alespoň zkusím dokončit. Důvodem byl fakt, že samotný „budoucí šéf“ byl kretén už od pohledu. Arogantní, který se snažil mi dát najevo, že on má pravdu a já jsem jen blb, co tomu nerozumí. Pohovor skončil tak, že jsme se spíše pohádali o tom, kdo má pravdu a já domů odcházel s pocitem naprosté vyčerpanosti. Při představě, že tenhle kretén bude můj šéf, se mi dělalo mdlo. Nabídku jsem tenkrát sice dostal, ale s upřímným poděkováním jsem odmítl.

Je velice těžké najít schopné šéfy týmů a je ještě těžší najít takové, kteří mají i odborné znalosti na to, aby byli schopni porozumět samotným programátorům. Ale než mít odborníka, raději mít šéfa, který na to má skutečně talent. Stejně jako každý nemá buňky na to, dělat programátora, tak ne každý může být manažer. Pokud nemám na výber, je lepší mít kouče než mentora. 

Pokračování příště….

Budoucnost webových služeb aneb REST není spása

NoSQL - Život nepodléhá třetí normální formě

BigData, NoSQL...

Asi každý se již setkal s těmito názvy, které jsou často spojovány se jmény jako je Google, Facebook či Amazon.

Co to vlastně znamená?

Díky rozmachu internetu na běžnou část populace, začalo docházet k exponenciálnímu nárůstu dat, které je třeba uchovávat a zároveň v nich "dolovat". Klasické relační databáze, které díky ACID udržují validní stav dat, se staly nevhodnou variantou. Ano, ani MS SQL a ani Oracle není vhodná databáze na Big Data.

Existuje mnoho důvodů, proč relační databáze není ideální variantou pro větší systémy. Zde je pár příkladů:

1. Vertikální škálování - tedy databázový stroj se nedá donekonečna výkonostně nafukovat
2. Pevná struktura - předem definovaná struktura dat, není pro vetší a rychle se měnící systémy, žádoucí
3. Migrace - Pro změnu struktury je často třeba sofistikovaná migrace přes SQL
4. SQL - dotazování pomocí tohoto jazyku je sice jednoduché, ale zároveň dost omezující

 Co tedy znamená NoSQL?

V první řadě by bylo vhodné říct, že označení NoSQL není zrovna vhodný název. Do této rodiny totiž dnes spadá několik typů databází. Pojďme si je v rychlosti projít:

Objektová databáze
První takzvanou NoSQL databází byla objektová. Šlo o to, že v době dominance objektově orientovaných jazyků (ještě stále to platí, nicméne funkcionální přístup ukazuje lepší koncept), se došlo do bodu, kdy mapování tabulek z relační databáze na objekty může být náročné. Vzniklo mnoho ORM knihoven, napříč všemi objektově orientovanými jazyky (C# - Entity Framework, Java - JPA, apod).  Proto vznikl koncept objektové databáze, která se snažila odbourat dané mapování a zvýšit tak výkon. Bohužel nikdy nedošlo k většímu rozmachu těchto databází a dnes se dá v podstatě říci, že se jedná o upadající koncept.

XML databáze
Označení není asi úplně správné, ale koresponduje přesně s tím, co takový typ databáze dělá. Jedná se o to, že data jsou ukládána v podobě XML dokumentů a jejich schématem je v podstatě XSD. Tento typ databází je vhodný zejména v případě složitých struktur jednotlivých dokumentů. Jistě bude stále existovat segment, kde tento druh databází bude využíván.

Key-Value databáze
Toto označení se vztahuje na databáze, které ukladají svá data do jakési hash mapy. Tedy klíč reprezentuje metadata a hodnota je reálná uložená hodnota. Tyto mapy jsou ukládány v blocích, které je unifikováno vlastním klíčem, který je použit pro přístup k daným datům.
První koncept přinesl Google, který dal světu Hadoop. Ten byl poté uvolněn pod Apache a stal se open source projektem. Pro dotazování se využívá přístup Map-Reduce.

Dokumentová databáze
Tento typ databáze vychází z principu key-value, kdy value reprezentuje dokument, což je struktura, nejčastěji reprezentovaná pomocí JSON formátu. Jednotlivé dokumenty mají svůj klíč v rámci celé kolekce a umožňují vazby na další dokumenty. Nejpopulárnější databází tohoto formátu je MongoDB.

Sloupcová databáze
Vychází z principu NoSQL databází s tím, že se nejvíce podobá relačním databázím. Data jsou reprezentována v tabulce se sloupci. Narozdíl od relační databáze je ovšem možné aby jednotlivé řádky obsahovaly jiné sloupce. Tedy nejedná se o pevnou strukturu v rámci celé tabulky.

Grafová databáze
Tento typ databáze je asi nesložitější a zároveň nejnovějším návrhem. Jedná se o to, že jednotlivá data mohou být propojována na další data pomocí vlastních vazeb. V té chvíli vznikají vazby jako: "uživatel vlastní", "role spadá do", apod. Grafová databáze umožňuje navrhnout strukturu tak, aby skutečně kopírovala reálný svět.

Správný výběr
V rámci projektu, na kterém v současné době pracuji, jsem hledal úložiště, které by mi splňovalo několik kritérií:

1. Úložiště musí mít horizontální škálování. Tedy bude možné přidáváním dalších virtuálních strojů, zvyšovat výkon.
2. Dostupnost je nejdůležitější vlastnost. Prominu úložišti dočasnou "zastaralost" dat, ale určitě ne výkyv v dostupnosti.
3. Bude docházet k častým změnám v modelu aplikace. Rád bych tedy úložiště, ve kterém nebudu muset dělat složité migrace.
4. Rád bych, aby databáze uměla zpracovávat JSON a to přirozenou formou. Nechci nic slyšet o formátech jako XML, apod. Nežijeme v pravěku.
5. Jelikož server API je GraphQL, tak bych rád databázi, pro kterou bude tento způsob přirozený.
6. Musí existovat možnost, jak se na databázi napojit přes Node.JS

Po sepsání základních požadavků, jsem se pustil do výběru hledání. Finále je vcelku jasné. MongoDB. I přes některá svá úskalí je to nejlepší varianta, která se dá zvolit. Splňuje základních 6 bodů, které jsem si dal.

Co MongoDB neumí?

Určitě se nedá říct, že tento typ databáze je spásou na vše. Tak například: "Těžko budete zařizovat bulk operace, jako hromadný insert. Dvoufázový commit sice MongoDB má, ale v tomto stavu se rapidně začně snižovat i výkon. Relace mezi daty si musíte hlídat v aplikaci."

Věcí, které při přechodu z klasických SQL databází člověk musí oželet, je více. Buď se s tím smíříte a nebo se vrátíte :)

Závěr

Většině databázistům jistě budou vadit dané nevýhody, které sebou tento princip přináší. Nicméně, kdo kdy navrhnul strukturu v relační databázi tak, aby mohl říci: "Jsem schopen obhospodařit jakýkoli požadavek na má data."? Odpověď je nikdo. A důvodem budiž třeba to, že život nepodléhá třetí normální formě.

Uvedu příklad, který jsem si vypůjčil z knihy "Big Data a NoSQL databáze":

Představte si situaci, že vlastníte stackoverflow.com, kde uživatelé pokládají otázky. V klasické relační databázi byste nejspíše měli tabulky jako otázka, uživatel. Uživatel by například obsahoval sloupec město, což by byla jeho aktuální adresa, kde bydlí. Samozřejmě by se uživatel mohl přestěhovat a tím by se změnilo i jeho bydliště. Vazba mezi uživatelem a otázkou by byla 1:N. Tady je zatím vše v pořádku, do doby, než dojde k požadavku, abyste zjistili, ze kterého města bylo pokládáno nejvíce otázek. V té chvíli by samotný návrh nebyl schopen obhospodařit tento požadavek. Sice jsme strukturu navrhli správně, nicménéně jsme si neuvědomili, že svět se nechová podle normálních forem. Asi by nám nezbylo nic jiného, než u změny bydliště si v čase uchovávat i změnu. Pak by nejspíše existovala tabulka bydliště, která by v podstatě musela udžovat změnu v čase.

Líbí se mi tento příklad. Ukazuje přesně to, že dopředu nikdy nemůžeme vědět, jaký bude požadavek na naše data. V dokumentové databázi se často data ukládají tak, že vazby jsou sice možné, ale nejsou hlavním stavebním kamenem. Jinak řečeno, v kolekci otázka by se uložila sice reference na uživatele, ale současně s tím i aktuální stav uživatele, tedy jeho jméno, adresa, apod. Ano porušili jsme sice normální formu, ale zároveň jsme umožnili vetší flexibilitu ohledně dolování dat. Navíc jsme se víc přiblížili realitě, tedy tomu, že v daném čase se uživatelka ještě nevdala a nezměnila příjmení a Franta ještě nebydlel v Praze, ale v Brně :)