abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 2
dnes 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 0
dnes 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 1
dnes 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 0
dnes 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
včera 21:00 | Nová verze

Byla vydána beta verze Linux Mintu 18.1 s kódovým jménem Serena. Na blogu Linux Mintu jsou hned dvě oznámení. První o vydání Linux Mintu s prostředím MATE a druhé o vydání Linux Mintu s prostředím Cinnamon. Stejným způsobem jsou rozděleny také poznámky k vydání (MATE, Cinnamon) a přehled novinek s náhledy (MATE, Cinnamon). Linux Mint 18.1 bude podporován až do roku 2021.

Ladislav Hagara | Komentářů: 0
včera 16:42 | Nová verze

Byl vydán Devuan Jessie 1.0 Beta 2. Jedná se o druhou beta verzi forku Debianu bez systemd představeného v listopadu 2014 (zprávička). První beta verze byla vydána v dubnu letošního roku (zprávička). Jedna z posledních přednášek věnovaných Devuanu proběhla v listopadu na konferenci FSCONS 2016 (YouTube, pdf).

Ladislav Hagara | Komentářů: 0
včera 15:16 | Komunita

Na GOG.com začal zimní výprodej. Řada zlevněných her běží oficiálně také na Linuxu. Hru Neverwinter Nights Diamond lze dva dny získat zdarma. Hra dle stránek GOG.com na Linuxu neběží. Pomocí návodu ji lze ale rozběhnout také na Linuxu [Gaming On Linux].

Ladislav Hagara | Komentářů: 1
včera 13:14 | Bezpečnostní upozornění

Byla vydána verze 2.7.1 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Řešeno je několik bezpečnostních problémů. Aktualizován byl především Tor Browser na verzi 6.0.7. Tor Browser je postaven na Firefoxu ESR (Extended Support Release) a právě ve Firefoxu byla nalezena a opravena vážná bezpečnostní chyba MFSA 2016-92 (CVE-2016-9079, Firefox SVG Animation

… více »
Ladislav Hagara | Komentářů: 0
30.11. 19:19 | Nová verze

Příspěvek na blogu nadace Raspberry Pi je věnován bezpečnostním vylepšením v nejnovější verzi Raspbianu s desktopovým prostředím PIXEL. V oficiálních obrazech je nově zakázán SSH přístup. Ten lze samozřejmě povolit po zavedení Raspbianu pomocí nástroje raspi-config. Nemá-li uživatel k Raspberry Pi připojený terminál, může SSH přístup povolit vytvořením souboru ssh v adresáři /boot. Raspbian nově upozorňuje uživatele na bezpečnostní riziko, je-li SSH přístup povolen a uživatel pi nemá změněno výchozí heslo.

Ladislav Hagara | Komentářů: 42
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 755 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: Pohled v PostgreSQL

9.7.2011 16:24 Kall Ell | skóre: 15
Pohled v PostgreSQL
Přečteno: 1178×
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?

Řešení dotazu:


Odpovědi

9.7.2011 17:07 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 09:36 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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
15.7.2011 09:53 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 10:27 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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
----------+---------------+----+------+---------
15.7.2011 11:51 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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á.
15.7.2011 12:13 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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
15.7.2011 12:21 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 12:30 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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 avatar 15.7.2011 12:32 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.7.2011 12:41 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
BAM! dík za podporu
15.7.2011 12:41 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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“.
15.7.2011 12:52 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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?
15.7.2011 13:20 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 13:47 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
> 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
15.7.2011 13:56 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 14:21 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
> 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 avatar 15.7.2011 14:28 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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í).
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.7.2011 14:38 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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
15.7.2011 14:47 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
tak já už sem se dokonce chytil

proč se tady dohaduju s Jirsákem když ani neví co je relační databáze? chjo
15.7.2011 14:43 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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á.
15.7.2011 14:52 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
> .. 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 avatar 15.7.2011 14:56 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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?
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.7.2011 14:27 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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 avatar 15.7.2011 14:30 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
16.7.2011 00:26 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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í.
16.7.2011 09:14 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
16.7.2011 11:09 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
16.7.2011 11:22 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
16.7.2011 11:33 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Kdo nevěří, ať si změří. Existují malé lži, velké lži a benchmarky.
16.7.2011 19:30 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
A měl jsi na CHARu nastaven constrain? A pokud ano, na kolik hodnot?
16.7.2011 19:59 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
16.7.2011 21:06 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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?
16.7.2011 22:20 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
16.7.2011 22:38 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
17.7.2011 00:09 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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...
17.7.2011 00:47 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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ý.
17.7.2011 12:55 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
17.7.2011 14:03 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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 avatar 15.7.2011 12:57 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Tak je konečná, nebo se do ní mohou přidávat položky?

Ano.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.7.2011 21:12 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 22:02 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Nerozumím té pomalosti. Proč je ENUM pomalý? Je snad pomalejší než číselník?
16.7.2011 19:30 l0gik | skóre: 22
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Naopak, enum je rychlý, ale hůře modifikovatelný. Pomalý je string a číselník.
15.7.2011 12:35 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 12:25 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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í.
15.7.2011 12:39 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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
15.7.2011 12:56 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 12:41 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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á.
15.7.2011 12:43 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Aspoň základní přehled: Třetí normální forma.
15.7.2011 12:57 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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 avatar 15.7.2011 13:03 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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š :).
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.7.2011 13:09 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
)) dík za radu, musim si to zapamatovat abych s tim neumětelem příště neztrácel čas
15.7.2011 13:21 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
2 a 4
15.7.2011 13:26 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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ý
15.7.2011 13:32 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Jaká je rozdíl mezi adresou a akcí?
15.7.2011 13:37 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
akce je jedna hodnota

adresa (aby neporušovala 1NF) je několik hodnot (ulice, čp, ...)
15.7.2011 13:48 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 13:53 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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
15.7.2011 13:07 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
  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.
15.7.2011 13:22 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
2. 3NF požaduje odstranění funkcionálních závislostí, čemuž ENUM nijak nepomáhá; čemu ENUM pomáhá je integrita dat
15.7.2011 13:30 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 13:51 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 14:04 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 14:23 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 14:39 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 15:00 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 15:07 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 15:42 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
budiž atribut akce prohlášen za atomickou hodnotu

výrobou číselníku tudíž databázi nenormalizuju
15.7.2011 17:07 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Tímhle způsobem je možné za normalizovanou prohlásit jakoukoli databázovou strukturu.
pavlix avatar 16.7.2011 00:27 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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é.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.7.2011 15:54 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 17:13 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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).
15.7.2011 17:31 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Jaká je skrytá strukturovaná hodnota slova 'smazano'?
15.7.2011 17:43 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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 :-)
15.7.2011 17:52 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:01 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:13 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:20 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:44 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:48 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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?
17.7.2011 15:50 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
> Nikdo jiný to za nesmysl neoznačil

tady a tady a možná i jinde
17.7.2011 16:34 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
17.7.2011 21:26 karlosko
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
17.7.2011 22:51 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
18.7.2011 00:35 karlosko
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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...
18.7.2011 08:10 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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ů.
18.7.2011 09:42 karlosko
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.

18.7.2011 11:45 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
18.7.2011 12:47 karlosko
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
18.7.2011 13:00 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
18.7.2011 13:31 karlosko
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.

18.7.2011 14:26 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
18.7.2011 14:55 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
18.7.2011 15:08 karlosko
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 14:25 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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
15.7.2011 14:50 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Odstranění těch volně psaných textových hodnot je normalizace.
15.7.2011 14:54 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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
15.7.2011 15:01 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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á…
15.7.2011 15:10 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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ší.
15.7.2011 15:18 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Protože když chcete podle něčeho filtrovat, musíte mít někde seznam přípustných hodnot.
15.7.2011 15:41 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 16:58 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 17:06 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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
15.7.2011 17:16 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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á.
15.7.2011 18:50 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
jenže ta tabule už je v 3NF ty kokote, ještě že už du domů, snad do zejtra na tuhle diskuzi zapomenu
15.7.2011 17:28 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 17:41 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 17:56 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:04 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:01 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:07 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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?
15.7.2011 18:24 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:41 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 15:12 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
> 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
15.7.2011 15:24 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 15:48 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
> 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
15.7.2011 17:06 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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í.
15.7.2011 17:15 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
> 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
15.7.2011 17:24 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 17:22 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:10 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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:-)
15.7.2011 18:16 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:35 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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...
15.7.2011 18:44 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:51 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 18:57 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Seznam Nováků nikdo nechce. Psal jste o tom, že někdo chce najít jednoho konkrétního Nováka.
15.7.2011 19:17 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 19:43 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
To tvrdím celou dobu, že každý chce jenom najít jednoho konkrétního Nováka, nikdo nechce filtrovat podle příjmení.
15.7.2011 20:10 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 20:19 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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 avatar 15.7.2011 15:00 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Odstranění těch volně psaných textových hodnot je normalizace.
Citation needed.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.7.2011 15:14 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Podle úvodního dotazu slovo 'smazano' není volně psaná textová hodnota, ale textová hodnota, která byla generována aplikací.
15.7.2011 15:18 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Takže jiná aplikace si tam může vygenerovat smazáno, jiná deleted, další XXX. To budou prima strukturovaná data…
pavlix avatar 15.7.2011 15:21 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Mám podezření, že si jenom děláte srandu. Protože číselník tomu, co píšete nijak nebrání.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.7.2011 15:26 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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ů“?
15.7.2011 14:48 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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 avatar 15.7.2011 15:08 pavlix | skóre: 53 | blog: pavlix
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Logy mají obecně statickou povahu, narozdíl od relačních dat.
GentooFedoraSCRAM – Jsem open source vývojář, nikoli markeťák ⇒ názory zde uvedené jsou jen mé vlastní.
15.7.2011 15:26 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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í.
15.7.2011 15:16 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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áží.
15.7.2011 15:34 Kit
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 16:55 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.
15.7.2011 17:08 jos
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
> 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
15.7.2011 17:18 Filip Jirsák | skóre: 66 | blog: Fa & Bi
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
Podle příjmení nebudete záznamy filtrovat, ale budete podle nich vyhledávat, když se snažíte najít jednoho konkrétního klienta.
15.7.2011 16:13 kuka
Rozbalit Rozbalit vše Re: Pohled v PostgreSQL
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.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.