Administrace komentářů

Právě ten příklad s občankou je dobrý - ukazuje zcela reálnou situaci, kdy se rozhoduji jak do databáze uložit občana a občanku a kdy mám chybný předpoklad, který musím později opravit.

Zprvu předpokládám, že každý občan má jen jednu občanku. Udělám tabulku občan a tabulku občanka příčemž občanka se bude odkazovat primárním (unikátním) klíčem na občana. Vznikne vztah 1:1.

Pak se dozvím, že občanek může mít ve skutečnosti občan více. Do tabulky občanka přidám nový klíč, který učiním primárním (unikátním), původní sloupec, který se odkazuje na občana nechám, akorát už nebude unikátní (na jednoho občana se může odkazovat více občanek). Vznikne vztah 1:N.

Jediné, co jsem musel upravit jsou klíče a v případné orm vrstvě getter a setter, kterým občanovi přiděluji občanku (nově musí akceptovat/vracet seznam).

Pokud bych dal všechny parametry občanky do tabulky občana, musím refaktorovat mnohem víc.

Na tom chci ukázat, že pro dvě různé entity jsou dvě tabulky se vztahem 1:1 vhodnější a flexibilnější než jediná tabulka s více sloupci a že se může hodit dekomponovat entitu na dvě entity a uložit je do dvou tabulek i případě, že to vypadá zprvu na evidentní 1:1 vazbu a máte třeba nutkání ji modelovat pouhým přidáním několika sloupců (tj. skalárních hodnot). Důvodem vhodnosti je právě to, že můžu snadno přejít ke vztahu 1:N (mimoto bude databáze sémanticky lépe odpovídat skutečnosti - občanka je něco jiného něž občan a můžou existovat i nezávisle).

Uvedená dekompozice je podle mě další možná geneze tabulek 1:1 (mimo rozšiřování databáze beze změn tabulek jak uvádí Šangala).

Otravuju s tím kvůli tomu, že nechci aby vznikl pro náhodného čtenáře dojem, že 1:1 je automaticky nějaká chyba, které by se měl vyvarovat (může to tak sice být ale také nemusí).

Nu a můj dotaz na vás se týkal právě toho, jestli byste to dával všechno do _jedné_ tabulky anobo zda říkáte "kdekoli mám _dvě_ tabulky ve vztahu 1:1 bych se měl rovnou zamyslet, zda tam nemá být spíše 1:N". Která varianta platí?