Dotaz: Postgresql arrays - rychlejší než redundantní data?

[vasek]

Ahoj. Mám databázi navrženou tak, aby v ní nedocházelo k redundancím a aby bylo hledání ce nejefektivnější. Poslední dobou ale databáze značně narostla a select nad joinem několika tabulek byl docela pomalý. Upravil jsem proto návrh tak, že jsem z několika nejvytíženějších "na sobě závislých" tabulek udělal jednu s redundantními daty. Je to sice plýtvání místem, ale také obrovské zrychlení, protože není potřeba spojovat tabulky. Toto sice hezky funguje, ale nelíbí se mi ta redundance. Neboť budu brzo převádět databázi ze současného mysql na postgresql, napadlo mě použít v postgresql arrays, abych se vyhnul redundanci. Je to hodně velká blbost? Jak to postgresql indexuje? Je to dost rychlé (bylo by tam hodně dotazů typu SELECT .. WHERE nejakadata = ANY (sloupec_1) AND .. AND nejakajinadata = ANY (sloupec_n))?

Odpovědi

[okbob]

Na datových strukturách podobných polím funguje např. PostGIS a funguje docela dobře:

http://www.postgresql.org/docs/9.1/static/intarray.html

[vasek]

No já bych používat i pole varcharů, textů, floatů ... Chci docílit tohoto:

jednoduchý příklad (není tady vidět redundance, ale je tu vidět to, o co se chci pokusit):

původně:
tabulka1 (normálně odkazuje na několik různých tabulek tzn. id_hodnota2 .. n)
--------
nazev(varchar) | id_hodnota1 ...
nejakynazev | 1

tabulka2
--------
id_hodnota1 | sl_1(int) ...
1 | 1
1 | 2
1 | 3

nyní:
tabulka
--------
nazev(varchar) | sl_1(int) ...
nejakynazev | 1
nejakynazev | 2
nejakynazev | 3

cíl:
tabulka
--------
nazev(varchar) | sl_1(int[]) ...
nejakynazev | {1,2,3}

[okbob]

Můžete mít pole libovolného typu - a použití také není nijak omezené - nedoporučuji ovšem pole používat místo vazebních tabulek.

[cronin]

Vám na prvej prednáške o relačných databázach nepovedali, že žiadna reálna aplikácia nefunguje v 3. normálnej forme?

[vasek]

Ne, jen že ve velice výjiměčných situacích.

[Kit]

Praxe nám ukazuje, že téměř všechny velké fungující webové aplikace jedou na 0NF. Můžeme tomu třeba říkat cache, ale de facto se jedná o totální denormalizaci.

[l0gik]

Osobně bych šel formou vazebních tabulek s tím, že bych pak vzal ty (rychlostně) nejblbější dotazy a k nim udělal automaticky aktualizované materializované pohledy. Z hlediska návrhu je to čisté, pokud nejde o neustále se měnící data (což bývá málokdy, většinou se data "přisypávají"), tak režie navíc bude zanedbatelná.

Optimalizátor postgresu je IMHO lepší než mysql, obzvlášť u složitějších dotazů, takže je možné, že to, co bylo v mysql pomalé bude v postgresu Ok.

[Kit]

Pole v PosgreSQL byla vytvořena proto, aby byla používána. Na druhou stranu je mi podezřelé, že chceš podle toho indexovat. Co znamená "značně narostla"? Víc než 1 Mzáznamů?

Číslování sloupců tabulky téměř vždy svědčí o chybném návrhu databáze. Podle vzorového SELECTu ty sloupce mají možná i svá jména nebo alespoň sémantiku. Proto se mi umístění do pole jeví jako nevhodné.

Možná by se daly využít R-stromy, ale z uvedeného příkladu mi vůbec není jasné, zda by to bylo vhodné řešení.