Minule se zde na Zdrojáku rozhořela debata pod tímto článkem. V diskuzi padlo dost argumentů proti SQL i pro SQL. V tomto článku se podíváme na to, jak by vypadal takový databázový návrh pro key-value databázi, a jak moc je odlišný od návrhu pro klasickou sql databázi. Také si shrneme výhody a nevýhody těchto řešení.

Mějme takové klasické zadání, na kterém si studenti ve škole trénují návrh SQL databází. V zadání nebudeme zabíhat příliš do detailů a nebudeme ho rozebírat více než je třeba.

Zadání je následující: Chceme vytvořit systém, který bude vypisovat program kin. Program může být týdenní nebo měsíční. V programu je uveden název kina ve kterém se hraje a adresa kina. Dále program bude obsahovat seznam filmů, což znamená, že u každého filmu bude jméno filmu, krátký popis, režisér filmu a také rok vzniku filmu. Dále bude možno vyhledávat, které kino hraje konkrétní film.

Pokud půjdeme na věc klasicky, jak nás to naučili ve školních škamnách, tak okamžitě rozpoznáme entity Kino a Film s tím, že entita Kino má atributy adresa a název. Entita Film pak rok, režisér, jméno filmu, popis. Tyto entity pak mají vztah m:n, protože Kino může hrát (třeba i nehrát, to zadání neříká) libovolný počet filmů, a stejně tak film může být hrán v libovolném počtu kin. E-R diagram pak bude vypadat následovně: