Příliš jsem nepochopil, v čem že spočívá to odlehčení pro server. Buď si výsledky naskládá/vyhází programátor v aplikaci, nebo to za něj udělá databázový server. UNION a spol jsou obyčejné množinové operace sjednocení (resp. průnik a podobně) - server je musí zkrátka "ručně" provést tak jako tak (v paměti nebo na disku - podle počtu dat - za použití indexové strategie pochopitelně).

Odlehčení by mohlo nastat za situace, kdy by to programátor dělal původně s pomocí dočasných tabulek, což je zvyk ze serveru MySQL, který v ranných verzích neposkytoval jinou možnost. Tohle je ovšem standardizovaná záležitost, kterou Postgres umí dlouho.

Hezký seriál, dneska večer jsem si ho prošel. Jen tak dál!

To je jednoduchý, řada lidí, zejména z řad začátečníků, má tendenci tohle řešit byť na serveru, ale ve svých scriptech, ať už se jedná o PHP, nebo Python. Nevím, nakolik se věnujete programování, ale i v kompilovaných jazycích mi vychází takovéto operace rychleji na serveru, než na aplikační úrovni, třeba už jen režie, kdy pošlu sekvenci dotazů a server musí každý analyzovat, vykonat, zpracovat výsledky a Ty mi vrátit.

Než jsem se dostal k PostgreSQL a FirebirdSQL, tak jsem taky všechno řešil na straně aplikace, nevěřil jsem, že stored procedury mohou být rychlejší, než sestavit složitý dotaz na straně aplikace, který pak předám a vezmu si zpět data. Pro zatím neobeznámené lidi z řad čtenářů, ta stored procedura je zanalyzovaná a server ví, které indexy bude používat a jaké hodnoty bude vracet, že jí předám data, která zafiltrují výstup, nebo jsou předlohou ke zpracování je bombónek.

No to je jasný, ale v čem je to odlehčení pro server?Jako že to uživatel nebude hloupě psát postupně? Tak to potom jo :-) Je samozřejmě neefektivní to dělat v aplikaci, výhodnější je využít prostředky relační algebry a vykonat to na serveru.

Programování se věnuju teoreticky i prakticky :-D Databázím zejména... PostgreSQL je fajn.

Latence s navazanim komunikace pada na cele spojeni se serverem. Z tohoto pohledu je tedy naprosto jedno, jestli v jednom spojeni udelate dva dotazy, nebo jeden, ktery bude slozenim techto dvou. Union ma smysl opravdu jen tehdy, pokud chceme jako vystup ten union. Snazit se tim o nejake optimalizace je pravdepodobne naprosty nesmysl.

A pro ty vase uvahy o rychlosti bych docela rad videl nejake platne argumenty, vysledky mereni, ci citace vasich zdroju.

Teda já zírám... souhlasím samozřejmě s Alešem. UNION je prostředek pro získání specifické množiny dat (sjednocení). Nemá nic společného s optimalizací. V situaci, kdy chceme ušetřit něco času při provádění dotazu nám mohou posloužit uložené procedury. Ty šetří čas tím, že server je předem "zná" a má "rozmyšleno", jak je nejrychleji obsloužit. To díky celkem sofistikovanému mechanismu nazvanému prováděcí plán.

Chcel by som sa spytat ako sa riesi vyhladavanie cez varchar ak chcem potlacit diakritiku.
Uzivatel zada :
číča a chcem aby sa to pretransformovalo na cica a teda potom aj vsetky zaznami pri search by sa transformovali.

nieco ako select xxx from clovek where nejaka_funkcia(xxx) like nejaka_funkcia(yyy).

Databazove kodovanie mam ako UTF8

a funkcia to_ascii() mi hodi unsupported encoding
a convert('xxx','UTF8','ASCII') mi pismena s diakritikou prelozi ako znaky v zatvorkach teda napr :
číča prelozi ako : (a1)(e8)(a2)(d3)(a1)(e8)(a2)a
co nie jo to hladam ;)

Dik za pomoc

To je jednoduche - musite ta data orezat uz ve chvili, kdy je tam vkladate. Nevim o zadnem indexu, ktery by byl schopen odstranovat diakritiku. Pak staci diakritiku odstranit i v dotazu.

Pokud se diakritiky nechcete vzdat, tak doporucuji vytvorit si novy sloupec, ktery bude obsahovat tytez informace, jen bez diakritiky. Bude slouzit jen ke hledani. Bude to poruseni 3. normalni formy, ale v tomto pripade je poruseni na miste (NF neni dogma).

A nebo vyuzijte fulltextovy modul TSearch2. O fulltextovem vyhledavani v Postgresu 8.X by mel vyjit tento tyden na serveru LinuxEXPRES.cz muj clanek. To by bylo asi nejidealnejsi reseni, protoze s timto modulem muzete delat dokonce (ceskou!) lematizaci slov (diky ispellu).

Dik moc ;)
pockam si na ten clanok a potom sa rozhodnem ;). Z hladiska performance by bolo asi lepsie vytvorit samostatny stlpec vsak ?

Určitě. Sice bude více dat v DB, ale to hledání pak bude mnohem rychlejší. Ten stlpec se totiž dá naindexovat.

No fulltext je rychlejsi nez like, takze spis ten fulltext...

Múžete prosím uvést url nebo název článku ? Nenašel jsem ho