Mno, nechci se dotknout pana autora, ktery je urcite znalec, ale 1NF vznikla jako historicky prehmat E. Codda koncem 60. let a od te doby se o ni siri dost bludy. V te dobe to mozna nekomu prislo primocare, ze data jsou pouze integery a retezce (viz Codduv paper), ale prece jen, doba pokrocila a v dnesni dobe neni zasadni problem (technicky ani logicky) mit jako data cokoliv, na cem lze definovat usporadani, coz jde klidne i na serializovanych objektech, mimochodem. Souhlasim s tim, ze LIKE je v podstate na pytel a pro lamy, ale argumentovat pri zduvodneni takovymi brontosaury jako je 1NF je mimo misu.
Ne tak úplně rozumím Vašemu příspěvku. Data klidně mohu mít serializovaná, ale musím mít bokem další informaci, kde mi co začíná (a případně končí). A teď záleží na tom, zpracovávaná data jsou ro nebo rw. Pokud mám strukturovaná data a odpovídající prostředky, tak jsem vždy schopný snadno vytahnou požadovanou podmnožinu dat a jsem schopný stejně tak snadno provést aktualizaci. Toto je praktický důsledek 1NF. Jde o to, aby se výpočetní síla neztrácela v zbytečném a opakovaném parsování. Pokud jsem schopný těchto činností, pak 1NF neporušují ani "nové" datové typy v SQL jako jsou struktury nebo pole. Vždy jsem tam schopný snadno pracovat jednotlivě (a to ať už s prvkem pole nebo položkou struktury).
1NF je zásadní z pohledu aplikačního vývojáře. Co je hlouběji, je už jiná oblast. Tam dochází k serializaci - a např. u PostgreSQL se serializuje celý záznam, nikoliv jednotlivé položky záznamu. Ale to už je pro programátora transparentní, a stará se o to systém.
Určitě si nemyslím, že by 1NF byla historický nesmysl. Zdaleka ne a nevidím jediný důvod, proč by 1NF měla v dohledné (nebo nějaké) době zaniknout¨¨¨¨¨
Přiznávám že jsem na tom stejně jako Pavel Stěhule, taky jsem nějak nepochopil co jste vlastně chtěl sdělit :-(
Naprosto nesouhlasím s tím že by 1. normální forma byla historický přehmat nebo snad nesmysl (ale budu rád pokud mne z mého života v bludu vysvobodíte). Totiž základní definice 1. normální formy říká jen a pouze to že se jedná o relaci, tj. podmnožinu kartézského součinu domén jednotlivých "sloupců". Tudíž 1. normální forma je naprostým základem relačních databází, protože je "spojkou" na relační algebru která je teoretickým základem relačních databází.
E. F. Codd (a další) k této základní definici přidává ještě podmínku atomičnosti dat, tj. to že každý sloupec obsahuje pouze dále "nedělitelné hodnoty" a to v tom smyslu že sloupec například obsahuje nejvýše jednu e-mailovou adresu (a nikoliv několik e-mailových adres oddělených například čárkami).
Poněkud mi také uniká smysl vaší zmínky o datových typech. Původní Coddův článek tu nemám, takže netuším jestli v něm skutečně pracoval pouze s dvěma vámi uvedenými datovými typy (integer a text), ale ani bych se tomu nedivil protože cílem jeho článku nebylo zavést kompletní plejádu datových typů ale definovat relační model dat. No a k tomu ty dva datové typy naprosto bohatě postačují, a celý článek je přehlednější.
Nehledě na to že konkrétní datové typy jsou pro samotnou definici 1. NF zcela irelevantní! Ona je to totiž pouze otázka kódování hodnot - je jedno zda datum uložím jako text v daném formátu, jako unix timestamp (tj. integer) nebo nějak jinak, pořád je to datum. A pořád jde o to jestli jsou hodnoty atomické, tj. dále nedělitelné!
No a vzhledem k tomu že se jedná o relaci a tedy vlastně množinu (která je ze své podstaty neuspořádaná), nechápu váš výrok "mit jako data cokoliv, na cem lze definovat usporadani". Zaprvé uspořádání je vždy definováno vzhledem k něčemu (sloupci, způsobu porovnání hodnot, apod.), zadruhé to s 1. NF nijak nesouvisí.
A je to asi ohraná písnička, ale můžete nám vysvětlit jak to myslíte s těmi serializovanými objekty? Pomiňme otázku koncepčních rozdílů mezi relačním a objektovým modelem dat - zajímá mne co vlastně myslíte tou serializací. Pokud serializujete celý objekt do jediného stringu která následně uložíte do jediného textového sloupce v klasické relační DB, tak hodně štěstí - to je totiž naprosto jasné porušení pravidel 1. NF a nekouká z toho nic dobrého! Pokud ale do databáze uložíte jednotlivé datové property objektu odděleně (tj. do samostatných sloupců), pak splňujete 1. NF a není to nic proti ničemu.
Ostatně přesně tohle dělají různé ORM nástroje (mapují objekty na relační tabulky a jejich property na sloupce), i objektové databáze (které definují "virtuální sloupce" nad serializovanými objekty které víceméně fungují jako ekvivalent řádek tabulky).
Naprosto s vámi souhlasím. Jenže v posledních letech se vyskytla potřeba ukládat do DB například XML. To se dnes řeší tak, že se do jednoho "stringového" pole uloží celé XML. To XML potom indexujete zvlášť. Jde svým způsobem o porušení první normální formy. Ovšem předchozí řečník to zcela nesprávně interpertuje tak, že 1NF je přežitý nesmysl. Taková interpertace nejspíš plyne z nepochopení problematiky.