Dotaz: Pohled v PostgreSQL

[Kall Ell]

Ahoj všem. Potřeboval bych poradit s jedním pohledem. Mám tři tabulky, z první TAB1 potřebuji načíst všechny záznamy, které obsahují ve sloupci act hodnotu nula. K tomu potřebuji z výsledného seznamu záznamů najít odpovídající záznam (ID řádku z TAB1) najít v TAB2. Kde podmínka je TAB1.ID = TAB2.ID. V TAB2 může být k jednomu záznamu z TAB1 několik záznamů. Ale v TAB2 hledám záznam, který bude obsahovat ve sloupci akce=smazano. Tomu bude odpovídat jen jeden záznam, ve kterém je mimo jiné ID uživatele, který záznam vytvořil. Místo ID chci vložit jméno. Nástin tabulek.

TAB1

id | nazev       | obec | ico    | dic      | act
---+-------------+------+--------+----------+------
15 | AAA s.r.o.  | Brno |12345678|CZ12345678| 0

TAB2
uziv | id | akce    | datum
-----+----+---------+---------
2    | 15 | smazano | 2011-7-9

TAB3 
id  |jmeno |prijmeni 
----+------+----------
2   |Jan   | Novák

požadovaný výsledek by měl vypadat takto

nazev       |obec   |ico      |dic        |datum    | jmeno  |prijmeni
------------+-------+---------+-----------+---------+--------+--------
AAA s.r.o.  | Brno  |12345678 |CZ12345678 |2011-7-9 | Jan    | Novák

Ty tabulky nejsou kompletní jsou větší, ale pro demonstraci to stačí. TAB2 je v podstatě log z TAB1 kam ukládám všechny změny provedené v TAB1. Act znamená jestli je záznam aktivní nebo je smazán(jelikož má vazbu i na jinou tabulku tak není smazán, ale označen jako neaktivní). Výsledná tabulka je seznam všech smazaných záznamů z TAB1 rozšířená o informace kdy byl záznam označen jako smazaný a kdo to udělal. Problém je, že si s tím nevím rady. Udělat to na straně PHP není problém, ale chci to udělat na straně serveru PostgreSQL. Máte někdo nějakou radu?

---

---

Odpovědi

[Filip Jirsák]

Rada je nastudovat si základy relačních databází. Tohle je to nejjednodušší spojení tabulek, nic jednoduššího už v relačních databázích nenajdete.

SELECT tab1.nazev, tab1.obec, tab1.ico, tab1.dic, tab2.datum, tab3.jmeno, tab3.prijmeni
FROM
  tab1
  JOIN tab2 ON (tab1.id = tab2id)
  JOIN tab3 ON (tab2.uziv = tab3.id)
WHERE
  tab1.act = 0
  AND tab2.akce = 'smazano'

Případně starým zápisem JOINu (mně připadá přehlednější):

SELECT tab1.nazev, tab1.obec, tab1.ico, tab1.dic, tab2.datum, tab3.jmeno, tab3.prijmeni
FROM tab1, tab2, tab3
WHERE
  tab1.id = tab2id)
  AND tab2.uziv = tab3.id)
  AND tab1.act = 0
  AND tab2.akce = 'smazano'

Také by to chtělo udělat normalizaci, ta akce asi nebude jen tak libovolný text – spíš budete mít omezený počet akcí, takže byste si na to měl udělat číselník a jenom se do něj odkazovat.

[jos]

to s tim číselníkem je IMHO nedobrá rada, v ukládání nějakýho umělohmotnýho intu žádnou denormalizaci nevidim a stinná stránka toho je, že když uvidim třeba hodnotu "2", tak se musim mrknout do toho číselníku abych věděl že je to "smazano"

check constraint nebo datovej typ to řeší daleko líp

[Filip Jirsák]

Normalizace databáze nespočívá v přidání umělého klíče, ale v odstranění duplicit. To, že se musíte podívat do nějakého číselníku, není na závadu, naopak je to u normalizovaných relačních databází úplně normální věc – málokdy budete mít v relační databázi všechna data pro jeden „dokument“ nebo „objekt“ pohromadě. Pokud dáváte přednost tomu vidět celý dokument nebo objekt najednou a nechcete používat normalizaci, použijte nějakou NoSQL databázi.

[jos]

uziv | id | akce    | datum
-----+----+---------+---------
2    | 15 | smazano | 2011-7-1
-----+----+---------+---------
3    | 16 | smazano | 2011-7-8
-----+----+---------+---------
4    | 17 | smazano | 2011-7-9

kterou normální formu tahle relace porušuje?

opakovaný výskyt hodnoty "smazano" není o nic víc duplicitní oproti jeho nahrazení nějakým intem a snižuje to čitelnost:

uziv | id | akce | datum
-----+----+------+---------
2    | 15 |   3  | 2011-7-1
-----+----+------+---------
3    | 16 |   3  | 2011-7-8
-----+----+------+---------
4    | 17 |   3  | 2011-7-9

tohle je porušení 3NF:

uziv_jmeno| uziv_prijmeni | id | akce |  datum
----------+---------------+----+------+---------
  Filip   |    Jirsák     | 15 | fubar| 2011-7-1
----------+---------------+----+------+---------
  Filip   |    Jirsák     | 16 | fubar| 2011-7-8
----------+---------------+----+------+---------
  Chris   |     Date      | 17 | snafu| 2011-7-9
----------+---------------+----+------+---------

[Kit]

V daném případě by se dal pro sloupec "akce" s výhodou využít datový typ ENUM. Uvnitř je hodnota číselná (1-2 B), navenek se prezentuje jako řetězcová, integritní omezení sloupce si ohlídá.

[jos]

sice sem nepsal přímo o ENUMu, ale věta "check constraint nebo datovej typ to řeší daleko líp" k tomu vybízí (bez implementačních detailů závislých na vendorovi SQL databáze)

každopádně upřesnění není nikdy na škodu

[Filip Jirsák]

Jak pak budete hledat všechny smazané záznamy? Pokusíte se uhodnout všechny názvy, jak mohla být ta akce nazvána? Tj. smazano, smazáno, deleted, removed, posláno do pryč… Nebo je to ve skutečnosti pořád jeden typ akce, takže tomu má odpovídat jeden řádek v relační databázi (v tomto případě tedy v číselníku)?

Použití výčtového typu by bylo možné, pokud byste věděl, že množina možných akcí je konečná. O čemž pochybuju, takže bych zvolil číselník, který můžu průběžně doplňovat o nové akce.

[jos]

samozřejmě že množina možných akcí je konečná a ano dává smysl do této množiny přidávat nové položky

nepoužívam postgres, takže nevim jak pracný je změnit ten ENUM, každopádně použít extra tabuli není jediná správná možnost, a IMHO je to ta nejhorší

v MSSQL kterou tu hákuju bych zvolil radši check constraint

a nedozvěděl sem se kde že sou ty duplicity

[pavlix]

a nedozvěděl sem se kde že sou ty duplicity

To mě taky zajímá. Páně Jirsák se stále arogantně ohání tím, že on jediný ví a chápe, co je relační databáze, ale vysvětlení duplicit zatím nikde.

[jos]

BAM! dík za podporu

[Filip Jirsák]

Tak je konečná, nebo se do ní mohou přidávat položky?

V PostgreSQL enum změnit nejde, musíte vytvořit nový, na ten všechny sloupečky převést, a pak starý zrušit. A je to celkem logické, výčtový typ, který nevypočítává všechny možnosti, by byl nelogický.

Pokud je uložení číselníku v samostatné tabulce podle vás nejhorší možnost, popište alespoň jednu lepší možnost.

Duplicity jsou ve sloupci „akce“, kde se vám opakuje textová hodnota „smazano“.

[jos]

je konečná v jednom časovým okamžiku, v druhým časovým okamžiku může mít položek víc

že je změna ENUMu složitá není důvod k tomu používat tabule

lepší možnosti sou: ENUM, check constraint

a když se ve soupci akce opakuje hodnota 666 tak to není duplicita?

[Filip Jirsák]

V jednom časovém okamžiku má konečné množství hodnot každá sada záznamů, pak by jaksi enum ztrácel význam.

Nejde jenom o přidání položky do enumu, těžko zařídíte třeba také přidání dalšího atributu. Pokud někdo nemá rád tabulky, nechápu, proč používá relační databázi. Je spousta jiných možností, jak ukládat data.

Check constraint je interní věc databáze, nemůžu se k té množině povolených hodnot dostat z aplikace. Takže až budu chtít uživateli nabídnout filtr podle typu akce, budu muset ten seznam opsat do každé aplikace a pak jej neustále udržovat. Nebo ta data můžu dát do samostatné tabulky, odkud si je může každá aplikace přečíst, že…

Když se ve sloupci opakuje odkaz na řádek jiné tabulky, není to duplicita. Nenechte se mást tím, že se jako identifikátory řádků zpravidla používají čísla, protože se s nimi lépe pracuje. Samozřejmě můžete jako identifikátor použít třeba řetězec, ale s tím se hůř pracuje jak počítačům tak lidem.

[jos]

> těžko zařídíte třeba také přidání dalšího atributu

pokud bych to potřeboval, tak mi nic nebrání ENUM zmigrovat do tabule, věci co nepotřebuju neprogramuju (YAGNI)

> Check constraint je interní věc databáze ...

konečně nějakej argument, nicméně i tohle de řešit - udržovat seznam hodnot na jednom místě a distribuovat ho; představte si, že i php aplikace můžou mít "instalátor"

> Když se ve sloupci opakuje odkaz na řádek jiné tabulky, není to duplicita

stejně tak když se ve sloupci opakujou hodnoty z dané množiny, tak to taky není duplicita

> Nenechte se mást tím, že se jako identifikátory řádků zpravidla používají čísla, protože se s nimi lépe pracuje. Samozřejmě můžete jako identifikátor použít třeba řetězec, ale s tím se hůř pracuje jak počítačům tak lidem.

blbost, u počítače to může tak akorát žrát víc paměti, lidem se pracuje líp se stringama; muj čas je dražší než procesorovej čas

[Filip Jirsák]

pokud bych to potřeboval, tak mi nic nebrání ENUM zmigrovat do tabule, věci co nepotřebuju neprogramuju (YAGNI)

Proč místo enumu nepoužít tabulku rovnou, když předpokládám, že mi enum stačit nebude? Není to o nic náročnější, než vytvořit enum (ve skutečnosti je to spíš jednodušší).

stejně tak když se ve sloupci opakujou hodnoty z dané množiny, tak to taky není duplicita

Když se opakují odkazy, duplicita to není, když se opakují hodnoty z dané množiny, duplicita to je.

blbost, u počítače to může tak akorát žrát víc paměti, lidem se pracuje líp se stringama; muj čas je dražší než procesorovej čas

U počítače to také může prodlužovat dobu přístupu – hůř se to indexuje, musíte z disku načíst víc dat… Lidem se líp pracuje s texty, pokud mají nějaký význam. Ale identifikátor řádku? Můžete zvolit nějaký syntetický text, ale ahWgay9z bude pro člověka mnohem horší, než 93. Nebo zvolíte nějaký významový identifikátor, který bude užitečný do té doby, než se význam daného řádku odliší od významu identifikátoru. Pak budete mít řádek s významem „varování“ pojmenovaný identifikátorem „chyba“, a lidi to bude akorát mást, protože budou mít tendenci tomu bezvýznamovému identifikátoru přikládat význam.

[jos]

> když předpokládám, že mi enum stačit nebude

ale já třeba předpokládam, že mi emun stačit bude

> Když se opakují odkazy, duplicita to není, když se opakují hodnoty z dané množiny, duplicita to je.

není, hodnota je vždycky hodnota ať už za ní stojí cizí klíč nebo ne;

> hůř se to indexuje, musíte z disku načíst víc dat

nevěřim že znáte HW a střeva db tak dokonale abyste si mohl tohle tvrzení dovolit; kecy sou levný, ukažte benchmark

> Lidem se líp pracuje s texty, pokud mají nějaký význam. Ale identifikátor řádku?

bavíme se o číselníku akcí s cca třema hodnotama, tak mi sem netahejte jiný příklady

syntetický id je syntetický bez ohledu na datovej typ; nesyntetický id sou pro člověka lepší pokud je možný je použít

pokud potřebuju použít syntetický id, tak samozřejmě obvykle sáhnu po intu, ale o tom se tu nebavíme

[pavlix]

Každý se musí jednou chytit. I já jsem se kdysi na Jirsáka chytil. Jirskák podle mě není blbec, ale dělá to schválně. Jeho diskuze patří obvykle mezi ty nejdelší (pokud se někdo chytí).

[jos]

IMO je blbec, zatvrzele odmítá zdarma načerpat vědomosti

naštěstí už bylo všechno řečeno, takže já tuhle diskuzi už prodlužovat nehodlám

[jos]

tak já už sem se dokonce chytil

proč se tady dohaduju s Jirsákem když ani neví co je relační databáze? chjo

[Filip Jirsák]

není, hodnota je vždycky hodnota ať už za ní stojí cizí klíč nebo ne;

Nesmíte se nechat zmást tím, že vazby mezi tabulkami jsou v relačních databázích z historických důvodů řešeny hodnotami a cizími klíči.

nesyntetický id sou pro člověka lepší pokud je možný je použít

Přičemž podle mne množina „kdy je možný je použít“ je prázdná.

[jos]

> .. vazby mezi tabulkami jsou v relačních databázích z historických důvodů řešeny hodnotami a cizími klíči

a jak se to bude v SQL databázích řešit v budoucnu?

> Přičemž podle mne množina „kdy je možný je použít“ je prázdná.

podle mě ne, v aplikaci kterou hákuju upouštíme od syntetických klíčů v číselnících ku prospěchu všech zúčastněných stran

[pavlix]

Nesmíte se nechat zmást tím, že vazby mezi tabulkami jsou v relačních databázích z historických důvodů řešeny hodnotami a cizími klíči.

Fíha, až takový úlet jsem nečekal… a relační logika jako nic, že?

[Kit]

Když se opakují odkazy, duplicita to není, když se opakují hodnoty z dané množiny, duplicita to je.

To znamená, že když uložím do tabulky opakovaná URL, tak to duplicita není? Jsou to také odkazy.

Odkazy na cizí klíče jsou také hodnotami z dané množiny. Pokud se opakují, _je_ to duplicita.

Zní to jako by v tabulce byly povoleny pouze primární a cizí klíče. Navíc všechny číselné.

Můžete zvolit nějaký syntetický text, ale ahWgay9z bude pro člověka mnohem horší, než 93.

My se ale nebavíme o syntetickém textu, to by byl skutečně lepší syntetický integer. Bavíme se o čitelném textu, který má vyjadřovací hodnotu. Pokud takový text nemá a nebude mít další atributy, je zbytečné ho cpát do další tabulky a generovat k němu další syntetické klíče.

[pavlix]

My se ale nebavíme o syntetickém textu, to by byl skutečně lepší syntetický integer. Bavíme se o čitelném textu, který má vyjadřovací hodnotu. Pokud takový text nemá a nebude mít další atributy, je zbytečné ho cpát do další tabulky a generovat k němu další syntetické klíče.

Ono to nelze obecně tvrdit dokonce ani o tom syntetickém textu.

[Kit]

U počítače to také může prodlužovat dobu přístupu – hůř se to indexuje, musíte z disku načíst víc dat…

Udělal jsem si takový maličký benchmark, který sice není příliš relevantní, ale nějaké hodnoty jsem z něj dostal. Udělal jsem si tabulku se třemi sloupci typu ENUM, CHAR(15) a FOREIGN KEY. Do ní 2.6 M záznamů. Potom jsem dělal select count(*) group by klíč; Zapsal jsem ze 3 měření vždy to nejlepší. Výsledky:

ENUM        3391 ms
CHAR(15)    4712 ms
FOREIGN KEY 8285 ms

Je patrné, že cizí klíč je nejpomalejší - to jsme všichni čekali. Vítězem se stal ENUM, ale ne o moc, v závěsu mu byl CHAR. Co však bylo horší, s aktivním cizím klíčem se zpomalil insert. Pochopitelně. Neměřil jsem o kolik.

Rozdíly jsou však tak malé, že je prakticky zbytečné rozhodovat se, které řešení použít, jen na základě výkonu. Chtěl jsem tím jen vyvrátit tvrzení, že použití číselníku je výhodnější pro výpočet. Nemusí to platit vždy a za všech okolností.

[Filip Jirsák]

Nic takového jsme nečekali. V PostgreSQL žádný datový typ „FOREIGN KEY“ není, takže bůhví co jste vůbec měřil. Taky jste nenapsal vůbec nic o charakteristice těch záznamů z hlediska indexů, takže výsledky toho testu jsou k ničemu. A příště, až zase budete vyvracet tvrzení o tom, že použití číselníku je výhodnější pro výpočet, nezapomeňte také napsat, kdo něco takového tvrdil.

[Kit]

To je jednoduché. Kdo chce, ten pochopí i mé nepřesné vyjádření. Kdo nechce, bude se vrtat v mých slovech. Kdo pochybuje o správnosti, ten si udělá vlastní experiment. Komu je to jedno, tak to ani nečte.

FOREIGN KEY není datový typ, to je jasné. Označil jsem tak měření s integritním omezením cizím klíčem. Kdo chtěl, pochopil.

[Filip Jirsák]

Spor byl o tom, zda je rychlejší přístup přes index nad číslem nebo nad řetězcem (nebo zda se to takhle obecně nedá určit). Takže vy jste měřil něco úplně jiného a navíc ani nevíte, co jste měřil. Integritní omezení se uplatňuje jen na operace měnící data, na čtení nemá vůbec žádný vliv.

[Kit]

Kdo nevěří, ať si změří. Existují malé lži, velké lži a benchmarky.

[l0gik]

A měl jsi na CHARu nastaven constrain? A pokud ano, na kolik hodnot?

[Kit]

Přiznám se, že neměl. Dodělal jsem check na 4 možné hodnoty řetězce ve sloupci, přeměřil jsem. Výsledky se nezměnily. Zřejmě by se to projevilo pouze při měření doby insertu nebo updatu.

[l0gik]

Tak to tam musíš mít něco špatně, protože mě integer vyšel o polovinu rychlejc než varchar - a to byl varchar ve tvaru "0", "1", "2", "3". A integritní omezení při selectu samozřejmě nic nezrychlilo ni nezpomalilo, v tom máš pravdu. Měl jsi na tom sloupci index?

[Kit]

Neměl jsem VARCHAR, ale CHAR(15). Index jsem na tom sloupci neměl, při procházení všech položek by se stejně neuplatnil. Nejspíš to zdržení udělal JOIN na číselník, ten je samozřejmě indexovaný INTEGER PRIMARY KEY.

[Filip Jirsák]

Měřit rychlost indexů bez indexů, to je vskutku originální. Měl jste na tom „benchmarku“ vlastně něco správně? To „zdržení“ neudělal žádný JOIN na číselník, ale vaše nepochopení toho, co děláte, proč to děláte, jak by měla vypadat ta databáze a jak by měl vypadat test. Jinak SELECT COUNT(*) … GROUP BY samozřejmě není procházení všech položek a index se při něm uplatní velice dobře. Záleží na typu indexu, ale většinou už tam ten počet bude uložen; a i kdyby nebyl, stačí spočítat ty položky v indexu a není nutné prolézat celou tabulku.

[l0gik]

Proč join na číselník? Na group by nepotřebuju žádnej JOIN. A když už joinuju, tak group by se nemá někdy úplně rádo s optimalizátorem, takže tomu musíš trochu pomoct:

select subselect.pocet, ciselnik.text from (select count(*) as pocet, cislo from tabulka group by cislo) subselect
inner join ciselnik on (subselect.cislo = ciselnik.cislo) 

A je to opět rychlejší než implementace pomocí varchar. Mě to vychází na mejch datech, kdy mám ve varchar políčku jen jeden znak 290ms ku 320ms, když bude varchar delší, tak se to ještě více rozrůzní. Jelikož enum je ve vnitřní reprezentaci int, a todle vychází stejně rychle s joinem jako bez joinu, tak bys na svejch datech měl dostat podobnej výkon, jako u enumu (kterej je interně int).

PS: Nevím, proč tady používat typ character, jakej má smysl, že se to doplní mezerama...

[Kit]

Skvělé, takže jsem se dostal na 3545 ms, tedy hned za ENUM.

CHAR jsem použil proto, že kdekdo tvrdí, že VARCHAR je pomalejší. Je vidět, že to platí jak kdy. Ještě to zkusím s VARCHAR, ale dnes už ne. Díky za sice složitější SELECT, ale výkonnější. Je vidět, že vnitřní optimalizátor není všemocný.

[l0gik]

Tip: There are no performance differences between these three types, apart from increased storage size when using the blank-padded type, and a few extra cycles to check the length when storing into a length-constrained column. While character(n) has performance advantages in some other database systems, it has no such advantages in PostgreSQL. In most situations text or character varying should be used instead.

[Kit]

V tom případě je téměř jedno, jestli použiji VARCHAR nebo TEXT. V případě potřeby omezení délky VARCHAR(limit). Pak už záleží jen na zvyklostech.

CHAR(delka) už jen tam, kde skutečně potřebuji pevnou délku doplněnou mezerami.

[pavlix]

Tak je konečná, nebo se do ní mohou přidávat položky?

Ano.

[l0gik]

V postgresu editovat enum jde. Do verze 9.0 editací katalogu - konkrétně tabulky pg_enum. Nevýhoda je, že to chce nadstandardní práva.

Od verze 9.1 na to bude normální příkaz.

Jinak, co se týče vaší dlouhý hádky, tak string s constrainem IMHO normalizaci neporušuje, dá se na něj nahlížet jako na nedělitelnou hodnotu. Je to však nejhorší varianta z string, enum a číselník, protože kombinuje nevýhody obého: špatnou modifikovatelnost typu a pomalost. Když se to měnit typ nebude, je enum daleko lepší, a pokud se to měnit bude, tak zas je lepší číselník.

[Kit]

Nerozumím té pomalosti. Proč je ENUM pomalý? Je snad pomalejší než číselník?

[l0gik]

Naopak, enum je rychlý, ale hůře modifikovatelný. Pomalý je string a číselník.

[Kit]

Změna výčtového typu je sice trochu kostrbatá, ale je možná.

U dobře navržené databáze se změny nedělají moc často.

[Filip Jirsák]

Ještě k tomu snížení čitelnosti – použití relační databáze vždy snižuje čitelnost, protože mapujete objekty z reálného světa na relační model. Tabulka v relační databázi nikdy nebyla zamýšlena tak, že bude reprezentovat celý objekt z reálného světa, vždy se předpokládá, že k získání všech informací o objektu budete muset tabulky spojovat (mimo pár nejjednodušších případů). Pokud chcete, aby jedna tabulka v relační databázi byla sama sobě čitelná, nepochopil jste princip relačních databází.

[jos]

experti jako vy obvykle přicházejí s osvědčeným řešením typu

data:

id | action | ....
------------+
 2 |  1     |
------------+
 3 |  2     |
------------+
 4 |  4     |

číselník

id | name   |
------------+
 1 | delete |
------------+
 2 | insert |
------------+
 4 | update |

přičemž když už bych byl nucenej použít extra tabuli (protože ještě nějaký data, případně potřebuju mít ještě slave tabuli závislou na tom číselníku), tak bych to udělal takhle:

data:

id | action | ....
------------+
 2 | delete |
------------+
 3 | insert |
------------+
 4 | update |

číselník

 id     |....
--------+
 delete |
--------+
 insert |
--------+
 update |

což splňuje moje nároky na čitelnost

princip relačních databází sem IMHO pochopil docela dobře

[Kit]

Ano, to je osvědčené řešení používané například v SQLite. Velmi snadná modifikace číselníku zvýhodňuje toto řešení před ENUM.

Není nutné mít číselné cizí klíče za každou cenu.

[Kit]

Ještě k tomu snížení čitelnosti – použití relační databáze vždy snižuje čitelnost, ...

Pokud chcete, aby jedna tabulka v relační databázi byla sama sobě čitelná, nepochopil jste princip relačních databází.

Principem normalizace je tedy, že z čitelných databázových tabulek děláme nečitelné? To snad ne.

Spojování tabulek relační databázi nedělá.

[Filip Jirsák]

Aspoň základní přehled: Třetí normální forma.

[jos]

a sám ste si to přečetl? který z těch pěti bodů na začátku tvrdí že použití textových hodnot (podpořených ENUMem nebo check constraintem) je porušení 3NF?

aspoň základní přehled o relačních databázích je tohle: úvod do relačních databází

[pavlix]

Jen upozornění, pan Jirsák je známý tím, že ho nikdy nikdo o ničem nepřesvědčí. Šetři síly na užitečnější úkoly, jestli můžeš :).

[jos]

)) dík za radu, musim si to zapamatovat abych s tim neumětelem příště neztrácel čas

[Filip Jirsák]

2 a 4

[jos]

2. Pro každou skupinu dat ...

skupina dat je třeba adresa apod., jeden sloupec není skupina (i když v relační algebře je samozřejmě množina o jednom prvku stále množinou)

4. Podmnožinu dat se shodnou hodnotou ...

stejný

[Filip Jirsák]

Jaká je rozdíl mezi adresou a akcí?

[jos]

akce je jedna hodnota

adresa (aby neporušovala 1NF) je několik hodnot (ulice, čp, ...)

[Filip Jirsák]

Akce může být stejně tak víc hodnot (identifikátor, název akce, název stavu po akci…), naopak adresa může být jedna hodnota (třeba identifikátor z UIR-ADR nebo text, který vám jako adresu zadá člověk, když ho nedonutíte adresu strukturovat). Vždycky záleží na tom, jak se daný objekt z reálného světa rozhodnete převést do relačního modelu.

[jos]

ano, může mít víc hodnot, ale vycházíme z tazatelovo zadání a tam tomu tak není, takže zase YAGNI

[Kit]

1. 3NF je soubor doporučení. Žádné dogma.
2. ENUM je de facto vytvoření číselníkové tabulky na nižší vrstvě. Tedy dělá přesně to, co 3NF požaduje na úrovni databázového systému.
3. Nikde není napsáno, že klíčový sloupec musí být číselného typu.

[jos]

2. 3NF požaduje odstranění funkcionálních závislostí, čemuž ENUM nijak nepomáhá; čemu ENUM pomáhá je integrita dat

[Filip Jirsák]

Toho, že může porušovat nějaká doporučení, si obvykle nejvíc užívá ten, kdo nechápe, k čemu jsou dobrá. Expert, který porušuje nějaké dobré doporučení, velice dobře ví, proč to dělá.

Enum je možné řešení, ale v tomto případě jsem si skoro jist, že se akce budou v budoucnosti přidávat, a možné je i to, že bude potřeba přidat nějaké další atributy. Navíc enum není dostupný ve všech databázích. Ale pokud bych věděl, že množina je opravdu konečná a že žádné další atributy nebudou potřeba, enum bych zvažoval.

Klíčový sloupec nemusí být číselného typu, ale lidem i počítačům se s tím lépe pracuje, když je to číslo. Ono totiž ve skutečnosti ani tak nemá jít o klíčový sloupec, ale má to být jednoznačný identifikátor daného řádku.

[kuka]

Tazatel pise, ze jde o log radkovych zmen v jine tabulce, tzn. mnozina akci se z technologickych duvodu velmi pravdepodobne menit nebude - insert, update, delete. Z hlediska normalizace na tom ovsem vubec nezalezi.

Zavedeni ciselniku pro hodnoty neni samo o sobe normalizace, muze jit maximalne o jakousi best-practice. 3NF omezuje nad ramec 2NF tranzitivni zavislosti mezi atributy, na coz vytazeni atributu do jine tabulky, kde neni zadny jiny atribut odvoditelny z klice tabulky puvodni, nemuze z principu mit zadny vliv.

[Filip Jirsák]

Množina akcí se nebude měnit do té doby, než si někdo vzpomene, že se má implementovat import, export a záloha.

Jinak já nejsem principiálně proti enumu, jenom mi připadá, že ve většině případů se bude s číselníkem v tabulce pracovat lépe. V té poznámce i šlo ale hlavně o to, že by to neměl být neomezený řetězec, do kterého si každý může zapsat, co ho napadne. Číselník v tabulce je nejuniverzálnější způsob, jak tohle vyřešit, ale samozřejmě není jediný. Dotaz ale nevypadal na to, že by bylo dobré pouštět se do detailního popisování toho, kdy by bylo vhodnější místo tabulkového číselníku použít enum, omezení, trigger, pravidlo, bitovou masku nebo některou ze stovek dalších specifických variant.

[kuka]

Ja primarne reaguju na tvrzeni o normalizaci, se kterou to podle mne nema nic spolecneho. Zatimco poruseni normalni formy bez zjevneho duvodu lze povazovat za chybu, pouziti/nepouziti ciselniku pro podobny pripad je bez podrobnejsich informaci vicemene esteticka zalezitost.

[Filip Jirsák]

Pokud máte v tabulce nějaký sloupec, který může nabývat nějaké množiny hodnot, a necháte tam ničím neomezený řetězec, není to estetická záležitost, ale to nejhorší, co můžete v relační databázi udělat.

[kuka]

Netvrdil jsem nic o zadnem "neomezenem retezci". Nicmene ani kdyby byl tento retezec neomezeny, nema to nejmensi spojitost s normalni formou. Nevadilo mi, ze vnucujes prevadeni na ciselniky, ktere ostatne v oduvodnenych pripadech pouzivam jako asi kazdy, ale zes to prezentoval jako vec normalizace, coz je pohled nespravny.

[Filip Jirsák]

Co je tedy podle vás normalizace? Zatím mi to připadá, že když si všechna data nacpu do jednoho velkého BLOBu a prohlásím to za jednu hodnotu, bude databáze podle vás normalizovaná.

Podle mne normalizace databáze znamená, že zkoumám strukturu databáze, a zjišťuju, zda to, co jsem dříve prohlásil za atomické hodnoty, nejsou ve skutečnosti strukturovaná data. Existují pak různé postupy, jak normalizaci provádět a kontrolovat ji.

[jos]

budiž atribut akce prohlášen za atomickou hodnotu

výrobou číselníku tudíž databázi nenormalizuju

[Filip Jirsák]

Tímhle způsobem je možné za normalizovanou prohlásit jakoukoli databázovou strukturu.

[pavlix]

Tímhle způsobem je možné za normalizovanou prohlásit jakoukoli databázovou strukturu.

Protože to pan Jirsák zakázal :D. Bohové.

[kuka]

Normalizace je v kontextu designu relacni databaze prevod (pripadne pokus o prevod) do urcite normalni formy. Kazda normalni forma ma jasne popsano, co je pro ni vyzadovano (i kdyz nektere veci se mohou historicky trochu lisit, napr. pristup k null). To tvrzeni o BLOBU nesvedci o prilisnem pochopeni konceptu normalnich forem, takova reprezentace by porusovala uz 1NF. Pokud jsi nekde zminoval 3NF, tak si ujasni, co to je - pokud mozno ne podle stranky na ceske wikipedii, ta je znacne podivna (co chce napriklad rict bod 4?). Jedna se o relacni teorii a ta jako takova neresi vykonnost - otazky jako zda je lepsi pouzivat jako identifikator tisiciznakovy retezec nebo dvouciferne cislo jsou z hlediska normalnich forem bezpredmetne, prestoze pro design databaze jsou jiste podstatne.

[Filip Jirsák]

Vy možná chápete normální formy po formální stránce, ale nechápete jejich význam. To, jestli je něco atomická hodnota, nebo struktura, je vždy otázka interpretace. Takže když si nadefinuju onen BLOB jako atomickou hodnotu která je zároveň primárním klíčem, mám vystaráno a databáze splňuje i 7NF. Normalizace databáze je právě postup, jak se nad těmi atomickými hodnotami zamyslet a prověřit, jestli to ve skutečnosti nejsou skryté strukturované hodnoty (resp. jestli je tak nechceme reprezentovat).

[Kit]

Jaká je skrytá strukturovaná hodnota slova 'smazano'?

[Filip Jirsák]

Skrytá strukturovaná hodnota atributu akce je ta, že je to omezená množina přípustných akcí. A nebo to opravdu může být atribut, kde je nějaká nestrukturovaná poznámka pro uživatele, pak tam skrytá strukturovanost není žádná. Ale pak by to chtělo, aby ta poznámka byla správně česky

[kuka]

Neni nic spatneho na tom, ze teorii neznas - take bych ji neznal, kdyby me ji nenaucili ve skole - teprve tim, jak to davas na odiv jako snad dokonce vyhodu, ze sebe delas hlupaka. Pouzivej pro svuj postup termin 'Jirsakova normalizace' a predejdes dalsim nedorozumenim.

[Filip Jirsák]

Já nejsem ten, kdo tady dává na odiv, že podle něj je perfektně normalizovaná databáze s jednou tabulkou s jedním atributem typu BLOB, do kterého se serializuje celý stav aplikace.

[Kit]

Pokud v takové databázi budu vyhledávat pouze pomocí primárního klíče a v uvedeném BLOBu budou například fotky, kusy webu, dokumenty nebo jiná nedělitelná data, tak taková databáze je perfektně normalizována.

[Filip Jirsák]

Ano, v takovém BLOBu budou fotky, kusy webu, dokumenty – všechno v tom jednom BLOBu. Vyhledávat tam podle primárního klíče nebudu, protože když budu mít databázi s jedním sloupcem a jedním řádkem, není moc co hledat. Navíc tím primárním klíčem bude ten BLOB, a abych podle něj mohl hledat, musel bych ho mít i v té aplikaci – pak by ale ztratilo smysl mít jej i v té databázi. Ale nemusí to být jen jeden řádek, můžu ten jeden velký BLOB rozdělit třeba podle velikosti na menší a ty uložit do více řádků a pak to po načtení zase spojit. Fantazii se meze nekladou.

[kuka]

A kdo teda? Napsal jsi to ty a vsichni ostatni, kterym to stalo za to, to - byt ruzne - oznacili za picovinu. Pokud bys nekdy narazil na 1NF, tak te to nevyhovuje a tedy ani zadne jine normalni forme.

[Filip Jirsák]

Nikdo jiný to za nesmysl neoznačil, naopak tady specifikujete takové požadavky na normalizovnaou databázi, kterým tahle struktura plně vyhovuje. Vy jste první, kdo přišel s tím, že to nevyhovuje 1NF – konkrétně tedy jak?

[jos]

> Nikdo jiný to za nesmysl neoznačil

tady a tady a možná i jinde

[Filip Jirsák]

To ale neoznačuje za nesmysl to použití, ale diskusi o tom. Co taky měli jiného autoři dělat – nedokážou napsat, jaké pravidlo NF a jak taková databáze porušuje, ale přiznat se jim to nechce. Tak prostě daný problém označí za nesmysl, a mají vyřešeno.

[karlosko]

Precti si lemple nejakou definici prvni normalni formy a nebrec, ze ti ji tady nikdo nechce poskytnout. Google snad pouzivas? Pokud si myslis, zes objevil jakysi "BLOBovy paradox", ktery vedcum, kteri ty normalni formy v relacni teorii zavedli, unikl, tak se nech pokud mozno rychle vysetrit.

[Filip Jirsák]

Další chytrák. A ještě neumí číst – nevšiml si, že se neptám na definici, ale na praktickou aplikaci. Já jsem si nějaké definice 1NF přečetl dávno. Jenže jsem v této diskusi asi jediný, kdo se nad přečteným také zamyslel a aplikoval to na nějaký příklad. Ostatní tady o NF pořád akorát žvaní, ale důsledně se vyhýbají tomu vzít nějaké konkrétní schéma a na to ta pravidla aplikovat. Můžu se akorát dohadovat, proč se tak bojí předvést své znalosti prakticky.

[karlosko]

Ty ses nad tim zamyslel, ale aplikujes na zaklade toho neco uplne jineho. Ja jsem normalizaci aplikoval mockrat na konkretnich "prikladech" (to ve skole) a pozdeji i v "realite", a zavedeni ciselniku jak ho popisujes s normalnimi formami vubec nesouvisi. Ty maji presne definovany vyznam, ktery si nemuzes ohybat podle svych dojmu. Podobne pokud se mi napriklad nelibi konkretni popis dat pomoci XML, nemohu o nem jednoduse rict, ze neni "well formed", na to musi porusovat nekterou z jasne definovanych podminek. To co nechapes je, ze normalizace neresi, zda je schema navrzene "spravne" - tyka se jen jasne omezene casti designu a navic i vecne nesmyslne schema muze byt ve vysoke normalni forme a naopak pro urcity typ problemu muze byt vhodna nizsi normalni forma. Pokud dosahnu urcite normalni formy, mam "pouze" zaruceny urcite vlastnosti takoveho modelu pri konkretnich operacich - a to stale jen v intencich relacni teorie, takze napriklad libovolna zmena datoveho typu (a ten tvuj ciselnik je pouze trivialni mapovani cislo-retezec) je proste irelevantni, to se tam vubec neresi.

Jestli sis precetl "nejake definice" prvni normalni formy davno, tak to ze nechapes, ze tvuj priblbly priklad s BLOBEM je s ni ve sporu, je opravdu s podivem. To, ze si myslis, ze ses jako jediny zamyslel, zes jako jediny pochopil atd. bude asi tak trochu diagnoza...

[Filip Jirsák]

Můj příklad s BLOBem může vyhovovat 1NF a nemusí. Záleží totiž na tom, co ten BLOB reprezentuje. Není totiž pravda vaše tvrzení, že věcně nesmyslné schéma může být ve vysoké normální formě. Normální formy totiž nejsou nic abstraktního, co by se dalo aplikovat bez znalosti významu dat, nýbrž právě naopak – posuzuje se to právě vzhledem k významu dat. Význam dat je samozřejmě něco, co interpretujeme, takže jednu a tu samou strukturu databáze může někdo považovat za normalizovanou a jiný ne, protože se neshodnou v interpretaci významu nějakého atributu (samozřejmě ten rozdílný způsob interpretace má jisté hranice).

Když se vrátím k té tabulce z dotazu, záleží na tom, jak interpretujeme význam atributu akce. Pokud to interpretujeme tak, že existuje několik různých typů akcí, každý ten typ akce má svůj název a do onoho sloupečku ukládáme právě ten název, pak taková tabulka samozřejmě nesplňuje 2NF, protože název typu akce nezávisí vůbec na ničem z dané tabulky. Atribut akce taky můžeme interpretovat jako volný textový popisek (de facto poznámka) určený jen pro zobrazení uživateli. Pak to normální formu neporušuje, a takovému atributu nastavím nejspíš nějaký typ dlouhého textu a možnost vkládat NULL. Další možná interpretace je, že ten atribut obsahuje nějaký identifikátor typu akce, přičemž ale samotné typy akcí už mne v databázi nezajímají. Pak to také odpovídá minimálně 3NF, ale zase budu pro atribut identifikátor volit nějaký odpovídající databázový typ – nejlépe enum nebo alespoň omezení s výčtem povolených identifikátorů. Z toho je taky vidět, že datové typy se sice neřeší přímo při normalizaci, ale řeší se při ní význam atributů, který pak logicky ovlivňuje datové typy.

Doufám, že teď už to pochopili i ti, kteří si mysleli, že normální formy se dají stanovit bez znalosti významu atributů.

[karlosko]

To prave vsichni nepochybne chapou. Klicove pojmy relacni teorie jsou klic, kandidatni klic, zavislost. Tyto vlastnosti atributu pochopitelne vychazeji ze skutecnosti, ktera se modeluje, to je tak zjevne, ze se snad o tom neni treba zminovat! Problem je v tom, ze ty zrejme za pomoci kristalove koule interpretujes trivialni text "insert" jako nazev jakesi komplexni entity "akce" a navic predpokladas, ze nazev neni jeji PK. Pak by samozrejme ten model byl nesmysl a to ne kvuli normalni forme, ale protoze by vazba na akci nebyla zachycena - to je ovsem jakysi hypoteticky model existujici jen ve tve hlave a mozna chapes, ze ostatni o nem nic nemohou vedet. Ze by akce mela nejake atributy ovsem z dotazu nijak nevyplyva a i kdyby tomu tak bylo, tak neni zadny duvod, proc by nazev akce nemohl byt primarnim klicem. Ty tady vnucujes, ze PK musi byt ve "spravnem" modelu cislo, ale minimalne z hlediska normalni formy to je uplne jedno. To je to co se ti rady mnoho lidi snazilo vysvetli a kdyz te budu parafrazovat, tak ted "uz jsi to doufam pochopil i ty" - ne ze bych tomu ale moc veril.

[Filip Jirsák]

To prave vsichni nepochybne chapou. … Tyto vlastnosti atributu pochopitelne vychazeji ze skutecnosti, ktera se modeluje, to je tak zjevne, ze se snad o tom neni treba zminovat!

V této diskusi to většina lidí nechápala, takže bylo potřeba to zmínit.

Problem je v tom, ze ty zrejme za pomoci kristalove koule interpretujes trivialni text "insert" jako nazev jakesi komplexni entity "akce" a navic predpokladas, ze nazev neni jeji PK.

Někdo jiný zase pomocí křišťálové koule interpretuje ten text jako poznámku pouze pro zobrazení a někdo jiný také pomocí křišťálové jako identifikátor akce, která je definována mimo databázi. Můžeme se bavit o tom, co je pravděpodobnější. Nicméně tazatel neuměl napsat ani jednoduché spojení tabulek, takže upozornit ho na to, že by se měl zamyslet i nad tímto atributem, rozhodně není na škodu.

neni zadny duvod, proc by nazev akce nemohl byt primarnim klicem

Důvodem je menší efektivita indexu nad řetězcem. Ale to není to, o co původně šlo – původně šlo o to, že (podle mne) v té databázi název akce není primárním klíčem, není to ani enum a ani tam není žádné omezení, protože si tazatel moc nepromýšlel, co ta jeho struktura databáze vlastně vyjadřuje. Tedy nemohl udělat ani normalizaci.

Ty tady vnucujes, ze PK musi byt ve "spravnem" modelu cislo

Nevnucuju. Jenom tvrdím, že když použiju umělý primární klíč, je z důvodu efektivity lepší použít číslo.

[karlosko]

Ted uz opravdu naposledy. Vytazenim JEDNOHO atributu X z tabulky A do samostatne tabulky B a jeho nahrazeni v A atributem Y predstavujicim odkaz do B NEMUZE byt ovlivnena treti normalni forma modelu. Pokud byl v teto forme pred akci, tak v ni zustane, pokud nebyl, tak v ni stale nebude. Atributy X a Y maji z hlediska relacni teorie presne stejnou zavislost na ostatnich atributech tabulky A, protoze vecne predstavuji TOTEZ. Nevim, jestli nerozumis tomuhle, nebo nechapes treti normalni formu, ale jedno z toho evidentne nastava.

[Filip Jirsák]

Já jsem ale nepsal o žádném vytažení atributu. Já jsem psal o tom, že se musí určit, zda nějaký atribut představuje atomické hodnoty, nebo zda ve skutečnosti představuje entitu, která se skládá z více atomických hodnot. A zda je něco atomický atribut nebo entita (soubor atributů), to už je předmětem normalizace.

[karlosko]

To uz se pouze trapne vykrucujes. Napsal jsi doslova:

Také by to chtělo udělat normalizaci, ta akce asi nebude jen tak libovolný text – spíš budete mít omezený počet akcí, takže byste si na to měl udělat číselník a jenom se do něj odkazovat.

1. Zda a jak moc je pocet akci omezeny je k normalnim formam irelevantni.

2. O zadne slozene hodnote se nezminujes. Je to celkem pochopitelne, u tazatelem uvadene hodnoty "smazano" opravdu neexistuje podezreni, ze by byla slozenou hodnotou - napr. ze by to slovo znamenalo sjednoceni nejakych sedmi elementarnich akci treba "soustruzeni", "montaz", "analyza", "zruseni" atd.

3. To co pises - udelat na to ciselnik a do nej se odkazovat - je presne to, co jsem vyse snad srozumitelne vysvetlil, ze s normalni formou nesouvisi.

4. Pokud ma akce nejake dalsi atributy, nema to opet na normalni formu zadny vliv, dokud je NEPRIDAM do te ZDROJOVE tabulky. V tom, co tazatel uvadi, toto nenastava, a ani nicim nenaznacuje, ze by se neco takoveho chystal udelat.

[Filip Jirsák]

Psal jsem o tom, že se musí určit, zda nějaký atribut představuje atomické hodnoty, nebo zda ve skutečnosti představuje entitu, která se skládá z více atomických hodnot. A zda je něco atomický atribut nebo entita (soubor atributů), to už je předmětem normalizace.

[jos]

pozor! rekurzivní diskuze

[karlosko]

Jak tedy upravis tu tabulku, ktera podle tebe neni ve treti normalni forme

TAB2 uziv | id | akce | datum -----+----+---------+--------- 2 | 15 | smazano | 2011-7-9

aby v ni byla? Napis to sem a kazdy si udela vlastni usudek, co vlastne ta tvoje "normalizace" obnasi. Pripadne muzes jako bonus vysvetlit, proc tabulka puvodni te forme nevyhovuje (to bych opravdu rad vedel) a tve nove reseni ano.

[jos]

svojí odpověď na dotaz ste zakončil větou:

Také by to chtělo udělat normalizaci, ta akce asi nebude jen tak libovolný text – spíš budete mít omezený počet akcí, takže byste si na to měl udělat číselník a jenom se do něj odkazovat.

kuka naproti tomu napsal, že výroba tý tabule není normalizace, takže doufam že konečně stáhnete ocas a nebudete se tu vydávat za experta

[Filip Jirsák]

Odstranění těch volně psaných textových hodnot je normalizace.

[jos]

a není, děte si přečíst něco o funkcionálních závislostech, pak to snad pochopíte a poděkujete všem který se vám to tady snaží vysvětlit

[Filip Jirsák]

Takže podle vás ten atribut akce je závislý jen na primárním klíči té tabulky? Můžu si do něj napsat, co chci, nikdy podle něj nebudu filtrovat? Mně to tak tedy nepřipadá…

[Kit]

Podle toho atributu filtrovat budu i když bude v číselníku. Tak proč ho do toho číselníku dávat? Jen to bude složitější.

[Filip Jirsák]

Protože když chcete podle něčeho filtrovat, musíte mít někde seznam přípustných hodnot.

[Kit]

Protože když chcete podle něčeho filtrovat, musíte mít někde seznam přípustných hodnot.

Třeba v ENUM nebo CONSTRAINT.

[Filip Jirsák]

Pokud máte seznam přípustných hodnot zadrátovaný někde v constraintu, nedokážete je procpat do aplikace, aby ty hodnoty dala uživateli na výběr. Z enumu to (alespoň v případě PostgreSQL) jde, i když to většinou bude pracnější, než dostat ta data z tabulky.

[jos]

to už tu bylo, můžu mít seznam někde jinde a zdrojáky pro check constraint generovat z něj

ale hlavně doufám, že už si pochopil že výroba extra tabule v tomhle případě neznamená normalizaci

[Filip Jirsák]

Vytvoření tabulky není jediný způsob, jak udělat tu normalizaci, enum nebo constraint jsou také možnosti. A pokud je to jen textová poznámka, která se má jen zobrazovat uživateli a nebude se podle ní filtrovat, pak tenhle atribut není překážkou pro to, aby databáze byla normalizovaná.

[jos]

jenže ta tabule už je v 3NF ty kokote, ještě že už du domů, snad do zejtra na tuhle diskuzi zapomenu

[kuka]

Ne kazdy atribut je potreba procpavat kamsi do formulare. Dale pokud pouzivam modelovaci nastroje, tak v tom neni zadny problem - definuji domenu a pro databazi se mi vygeneruje constraint nebo trigger (nebo i ten ciselnik) podle toho, jak si to zadam. Pro aplikaci v jave se mi vygeneruje odpovidajici trida nebo enum podle toho, jak si to zadam. Pro frontend se mi muze vygenerovat validacni a lokalizacni kod - ze by se uzivatelum naprimo ukazovalo, co je pro hodnoty z domeny ulozeno v databazi, je v enterprise resenich spise vyjimecne. Tak se to dela podle me zkusenosti na velkych projektech a neni to absolutne ani lepsi ani horsi, kazdy ze zpusobu ma sve vyhody a nevyhody v kontextu sveho pouziti.

[Filip Jirsák]

Když jsem závislý na tom, že mi to nějaký nástroj procpe do Javy, pak už vůbec nemá smysl cpát to do databáze jako nějakou smysluplnou hodnotu – naopak si tím akorát přiděláte práci. Ostatně, v případě ORM nemá moc smysl bavit se o nějaké normalizaci databáze, protože se musíte podřídit hlavně tomu, co ten který nástroj dokáže nějak rozumně mapovat. A zrovna v tomhle případě by ten ORM nástroj vedl jedině na číselník v tabulce, protože výčtový typ neumí každá databáze, tak se nikdo nebude dělat s výjimkou, a constraint bude tomu ORM k ničemu, protože to potřebuje hlavně ty hodnoty.

[Kit]

V tom případě nepotřebujeme žádné komplexní SQL databáze, ale stačí nám jen ORM->KVS. To je blbost, co?

Integritní omezení v databázi mají svůj význam jako poslední ochrana před neplatnými vstupními daty. Je nutné dávat přednost interním omezením před externími.

[Filip Jirsák]

Ono by to kolikrát těm aplikacím nad ORM postaveným jenom prospělo. Ale tady se bavíme o pravém opaku, o tom, jak udělat správně strukturovanou databázi, a to je v přímém rozporu s automatickým ORM.

[kuka]

O zadnem ORM zde nebylo reci - to je bohuzel v diskusi s tebou neustale, ze porad neco podsouvas.

Typ retezec prave umi kazda databaze a je obstojne citelny i pro cloveka, proto je pro reprezentaci hodnot domeny tak popularni. Na projektech co delam se vyviji vzdy pro konkretni databazi (zakaznik za jeji extra vlastnosti plati spousty penez), takze zadne vyjimky neni treba resit. O normalizaci je treba se bavit vzdy a legitimnim zaverem muze byt naopak denormalizace, napriklad v datovych skladech.

[Filip Jirsák]

Takže ten váš modelovací nástroj navrhne javovské třídy, které nepoužívají hloupé ORM, ale používají správně pohledy a uložené procedury nad databází? Můžu znát jméno toho nástroje?

[kuka]

PowerDesigner, Enterprise Architect, neznam aktualni stav Rational, ale nepochybuju, ze ten toho umi jeste vic. Javovske tridy reprezentuji entity, jak se udela persistence je samostatna otazka a obvykle to resime vlastni silou bez ORM kvuli vykonu.

Se slovem "spravne" bych setril. Pohled je view? Pokud ano, tak proc by ho nastroj nemel umet, to je dost elementarni vec. Co je obecne spravneho na ulozenych procedurach? Nekdy je pouzivame, ale vetsinou na podporu ruznych udrzbarskych cinnosti, externich loadu apod., aplikacni logika byva na aplikacnim serveru a ne v databazi. Nicmene nastroj by je vygenerovat umel, trivialni (napr. validace dat na triggerech) sam, u slozitejsich pripravi kostru treba podle nejakeho templatu. Vse pro Oracle.

[Filip Jirsák]

Používat správně pohled znamená, že programátor nebude matlat SELECT … JOIN do kódu, ale použije už připravený pohled. Jedna třída pak samozřejmě může být načtena z různých pohledů, podle situace. Uložené procedury jsou dobré k tomu, když potřebuju nějaký objekt zapsat do databáze nebo ho updatovat. Všechno to záleží jenom na tom, jak moc má být databáze samostatná a sama zajišťovat správnost dat, nebo zda se to ponechává spíš na aplikaci a databáze je jen hloupé úložiště. Už nějakou dobu se to bohužel posouvá k tomu druhému, takže databáze je pak někde jen nepohodlný nástroj, ze kterého několika SELECT * FROM dostane programátor data, a pak si je konečně může v aplikaci spojit, vytřídit a seřadit.

[jos]

> Takže podle vás ten atribut akce je závislý jen na primárním klíči té tabulky?

ano

> Můžu si do něj napsat, co chci

když tam bude ENUM, nebo check constraint nebo cizí klíč, nebo whatever, tak ne

sme pořád ve stejný diskuzi? proč musim všechno opakovat třikrát?

> nikdy podle něj nebudu filtrovat? Mně to tak tedy nepřipadá…

možnost filtrování s tim nijak nesouvisí, pokud někde požaduju výkon, tak použiju index, pokud někde požaduju od databáze aby hlídala integritu, mam na to jiný prostředky

[Filip Jirsák]

Když tam bude enum, omezení nebo cizí klíč, už ten atribut není závislý jen na primárním klíči. Možnost filtrování s tím souvisí – normalizace se dělá právě proto, aby se pak nad těmi daty daly použít schopnosti relačního databázového stroje, který je na tohle už 40 let optimalizován. Samozřejmě, že můžu i do relační databáze jako jeden BLOB serializovat celý stav programu, ale pak mi ten relační databázový stroj bude k ničemu.

[jos]

> Když tam bude enum, omezení nebo cizí klíč, už ten atribut není závislý jen na primárním klíči

z pohledu funkcionální závislosti v rámci relace ano, a to je to podstatný o čem tu mluvíme (primárně 3NF)

> Možnost filtrování s tím souvisí – normalizace se dělá právě proto, aby se pak nad těmi daty daly použít schopnosti relačního databázového stroje

nesouvisí, nedělá

mějme relaci

id | nazev
---+-----------
15 | AAA s.r.o.

s jediným constraintem - primární klíč nad atributem id

můžu filtrovat záznamy podle atributu nazev? ano. pokud tam mam milióny záznamů, pořídim nad atributem name index

ty kecy o blobu si strčte za klobouk

[Filip Jirsák]

ty kecy o blobu si strčte za klobouk

To je asi to jediné, co k tomu můžete říci. Jinak by se ukázalo, že takový BLOB splňuje všechny vaše požadavky na normalizovanou databázi.

V normálně strukturované databázi se samozřejmě nebudou používat volné texty pro číselníkové hodnoty, podle kterých se navíc má filtrovat. V normálně strukturované databázi se také nebude filtrovat podle názvu, bude se podle něj nanejvýš hledat. A taky se v normálně strukturované databázi nebude vše řešit „vytvořením indexu“, ale nejprve se podle ukládaných dat logicky navrhne struktura tabulek a vazeb. Ale toho si nevšímejte, to jsou mnohem přísnější požadavky, než které vy nazýváte normalizovanou databází.

[jos]

> To je asi to jediné, co k tomu můžete říci.

jo, protože je to naprostá píčovina o který nehodlam diskutovat

> ... se také nebude filtrovat podle názvu, bude se podle něj nanejvýš hledat ...

jakej je rozdíl mezi hledáním a filtrováním? sou snad pro ty operace dvě rozdílný verze WHERE klauzuje?

index sem zmínil jako výkonnostní nástroj, nic víc, nic míň

kdybys viděl databázi kterou tady spravuju, tak bys asi padl na zadek, není to žádnej blogísek nebo podobná sračka se kterou nejspíš děláš ty

[Filip Jirsák]

Filtrování je nalezení záznamů, které splňují nějaké podmínky. Třeba výběr všech podřízených nějakého zaměstnance, výběr všech výrobků v určité kategorii e-shopu, výběr všech účtů se zůstatkem vyšším než 1MKč… Hledání je nalezení jednoho konkrétního záznamu podle nějakých identifikátorů. Obojí se zapisuje v SQL přes WHERE, protože z hlediska relační databáze se hledání dá převést na filtrování. Ale z hlediska struktury dat je to každé něco jiného.

[Kit]

V normálně strukturované databázi se také nebude filtrovat podle názvu, bude se podle něj nanejvýš hledat.

Nějak mi uniká rozdíl mezi hledáním a filtrováním.

[kuka]

Jak jsem pochopil tak 'filtrovat' a 'hledat' je podle tebe neco jineho, coz pouze s usmevem prijmu jako dalsi z novinek, ktere my starsi jeste nezname - nechystas se to publikovat? Jak tedy tvoje normalne strukturovana databaze, kde se nefiltruje podle nazvu, bude resit ukoly typu zobraz vsechny firmy zacinajici pismenem 'K'?

K tomu BLOBU jen nevyzadana dobra rada - tim, zes vubec takovou totalni hovadinu napsal, sis poradne nasral na hlavu, tak to alespon uz dal nerozmazavej

[Filip Jirsák]

Když budu takovou hloupost, jako zobrazit všechny firmy od „K“ potřebovat, tak podle názvu budu muset filtrovat. Ale vzhledem k tomu, že něco takového ještě nikdy žádný uživatel nepotřeboval, a používá to jedině tehdy, když mu programátor nedá možnost používat program normálně, řešil bych raději to, jak dát uživateli k dispozici takové nástroje, které skutečně potřebuje.

K tomu BLOBu není co rozmazávat – já se za to nestydím, že takovou databázi nepovažuju za normalizovanou. A je mi jedno, že vy a pár dalších takovou databázi považujete za krásný příklad normalizované databáze až do 7NF.

[kuka]

Videls treba uz nekdy aplikaci, kde postupne upresnujes filtr a nabizeji se ti moznosti? Zkus treba jizdni rad. Moje zkusenost je, ze toto je naprosto killer feature, kterou kazdy chce pokud mozno vsude. Nebo treba vyhledavani podle prijmeni - vis kolik je v databazi stredne velke banky Novaku? A budes se divit, uzivatele je obcas chteji vsechny zobrazit a jednoho z nich si pak vybrat, napriklad kdyz jim Novak zatelefonuje. Jiste, delaji to jen proto, ze jim hloupy programator nedal nastroje, ktere skutecne potrebuji - napriklad modul, ktery uhodne, ktereho Novaka maji na mysli, pripadne pohodlny formular, kam musi vyplnit jeste komplet adresu a vek, aby se jim ztotoznil...

[Filip Jirsák]

No vidíte, že dokážete sám přijít na to, jak může fungovat rozumné vyhledávání. Když to navrhnete takhle, tak pak uživatel nebude mít potřebu používat filtr, když ve skutečnosti chce něco vyhledat.

[kuka]

A ten seznam vsech Novaku jim nabidnes jak bez pouziti filtru? Ironizace mi v mem veku uz nevadi a opravdu, uz jsem radu aplikaci s vyhledavanim navrhl. Verim, ze jsi blbec, ale takovy, jak prezentujes, prece jen asi ne - spis nemas co delat a chces provokovat. No take jsem nemel dnes prilis co delat, ale to ted konci a tim i muj sparring ve tve one-man show.

[Filip Jirsák]

Seznam Nováků nikdo nechce. Psal jste o tom, že někdo chce najít jednoho konkrétního Nováka.

[Kit]

Problém je v tom, že ho chce každý, aby mohl najít toho jednoho konkrétního Nováka. Najde ho jedině filtrem.

[Filip Jirsák]

To tvrdím celou dobu, že každý chce jenom najít jednoho konkrétního Nováka, nikdo nechce filtrovat podle příjmení.

[Kit]

Tak ještě jednou: Seznam Nováků chce každý, aby mohl najít toho jednoho konkrétního Nováka. Najde ho například filtrováním podle příjmení. Z tohoto seznamu si teprve vybírá toho pravého.

A protože Nováků je hodně, jedná se o duplicitu, kterou by ses měl snažit odstranit nejlépe umístěním do jiné tabulky a místo příjmení dát jen cizí klíč integer. Totéž s křestními jmény (tam je hromada duplicit), názvy ulic i měst. Nevím, jestli je pro tebe PSČ dostatečně normalizováno, tak možná i to. Budeš normalizovat i rodná čísla? Podle těch se občas také vyhledává a je to string.

[Filip Jirsák]

Tak ještě jednou: seznam Nováků nechce nikdo, každý chce jen najít toho jednoho konkrétního Nováka. Úkolem autora aplikace je pak to hledání co nejvíce usnadnit – například pokud uživatel zadá nejednoznačný vstup, nabídnout mu všechny možnosti, které mu odpovídají, aby si z nich mohl vybrat.

Evidentně jste pořád nepochopil, že normalizace se netýká hodnot, ale významů atributů. Takže operovat nějakými duplicitami v hodnotách je nesmysl.

[pavlix]

Odstranění těch volně psaných textových hodnot je normalizace.

Citation needed.

[Kit]

Podle úvodního dotazu slovo 'smazano' není volně psaná textová hodnota, ale textová hodnota, která byla generována aplikací.

[Filip Jirsák]

Takže jiná aplikace si tam může vygenerovat smazáno, jiná deleted, další XXX. To budou prima strukturovaná data…

[pavlix]

Mám podezření, že si jenom děláte srandu. Protože číselník tomu, co píšete nijak nebrání.

[Filip Jirsák]

Vy opravdu nevidíte rozdíl v definici dat „tady může být některá z akcí přidáno, upraveno, smazáno, importováno, exportováno, zazálohováno“, a v definici „tady může být řetězec s maximální délkou 255 znaků“?

[Kit]

Toho, že může porušovat nějaká doporučení, si obvykle nejvíc užívá ten, kdo nechápe, k čemu jsou dobrá. Expert, který porušuje nějaké dobré doporučení, velice dobře ví, proč to dělá.

Každý databázový specialista ví, že po úspěšné normalizaci musí provést i denormalizaci. Jinak ta aplikace bude líná až nepoužitelná.

Pokud potřebuji do databáze sypat logy, tak normalizaci dělat nebudu, to dá rozum. Dokonce nebudu dělat ani silná integritní omezení.

[pavlix]

Logy mají obecně statickou povahu, narozdíl od relačních dat.

[Kit]

Na druhou stranu logy obsahují obrovské množství duplicit, jejichž odstraněním by se ušetřila hromada místa na disku. Také jejich následné zpracování by bylo jednodušší. Pro aplikaci je však obvykle výhodnější je sypat do textového souboru hlavně kvůli úspoře času při jejich vytváření.

[Filip Jirsák]

Pokud budu do relační databáze sypat logy, tak především vím, že databázi zneužívám k něčemu, k čemu není určená. Akorát se mi shodou různých historických okolností hodí veškerá ta infrastruktura okolo, ukládání velkého množství dat, indexování a vyhledávání – a samotná relační databáze mi u toho moc nepřekáží.

[Kit]

Jenže tazatel do databáze ty logy ukládá a potřebuje v nich občas vyhledávat. K takovému účelu ta databáze je určena.

[Filip Jirsák]

Myslíte, že by ten atribut „akce“ byl jenom nějaká poznámka nebo komentář, který se má zobrazit uživateli a který nemá žádný strukturální význam, nebude se podle něj dotazovat? Tahle varianta mne při pohledu na tu tabulku vůbec nenapadla, je to bez háčků a čárek, jednoslovné… Ale pokud by to tak bylo, pak samozřejmě nemá smysl nad tím cokoli dalšího vymýšlet, naopak, čím méně omezení, tím lépe.

[jos]

> Myslíte, že by ten atribut „akce“ byl jenom nějaká poznámka nebo komentář, který se má zobrazit uživateli a který nemá žádný strukturální význam, nebude se podle něj dotazovat?

záleží na tom? když mam v databázi klienty tak se taky můžu dotazovat na záznamy podle příjmení, i když na to nemam číselník

[Filip Jirsák]

Podle příjmení nebudete záznamy filtrovat, ale budete podle nich vyhledávat, když se snažíte najít jednoho konkrétního klienta.

[kuka]

Miluju tyhle jednoznacny moudra lidi, co vsechno vi. Jakto ze neni k tomu urcena? Kazda databaze je snad urcena k ukladani dat a neni to zadna shoda historickych okolnosti. Log muze byt relace jako kazda jina a velmi casto ho potrebuju davat do souvislosti s jinymy daty systemu. Kam jinam nez do databaze by se mely ukladat napriklad logy o transakcich provadenych mezi bankami? Nikdy jsem nevidel, ze by nekdo data takoveho charakteru ukladal jinam nez do relacni databaze. Ze si nebudu do databaze cpat log z debugovani sveho ceckoveho programu je uplne jina pohadka.