Vlákno názorů k článku PostgreSQL: připravené dotazy a oddělení dat od dotazů od pajout - Životnost dotazu v paměti je dána délkou trvání...

Životnost dotazu v paměti je dána délkou trvání vaší session se SQL serverem. Jinak řečeno po odhlášení a ukončení spojení jsou z paměti serveru odstraněny i všechny uložené dotazy.
- Je docela skoda, ze dotazy nejsou perzistentni skrz databazove sessions. I kdyz se webovy server nepripojuje znova pri kazdem vyrizovani stranky, prece jenom se v zavislosti na provozu muze pripojovat relativne casto. Navic, dotaz musi byt pripraven pro kazdou jeho instanci znova... Ze by autori cashovali pripravene dotazy na zaklade dvojice (syntax, user), nikoliv semantiky dotazu ? (select * from my_view nemusi nutne delat pro ruzne uzivatele to same)

PG pochopitelne podporuje VIEW, ktera jsou persistentni a jedna se o neco naprosto jineho nez PREPARE/EXECUTE. PG ma pro kazde spojeni samostatny proces a cache je v jeho vlastni pameti(tedy nezdilena) a ulozena jak je v _clanku_ reseno podle nazvu dotazu tedy nic ohledne syntaxe a username.

Ano, nevsiml jsem si poradne 'PREPARE myquery (text) AS ...'.
Presto bych uvital vysvetleni, co je hlavni pricinou toho, ze pripravene dotazy NEJSOU sdileny v shared memory, aby mohly byt vyuzity v ostatnich sessions. Napriklad 'PREPARE [PUBLIC|USER] myquery...' - pripraveny dotaz by bylo mozno deklarovat jako verejny nebo platny pouze pro stejneho uzivatele.
Postgresi views znam, uvadel jsem jen jednoduchy priklad, kdy syntakticky totozny dotaz, konkretne retezec 'select * from myview;' nemusi nutne vracet stejna data pro ruzne uzivatele, i vysledek optimalizace tohoto dotazu muze na uzivateli zaviset.

To vim naprosto presne protoze prvni experimentalni implementaci PREPARE/EXECUTE jsem psal ja a ukladani do sdilene pameti podporovala. Ale... bylo to vyhodnoceno jako neco kde vyhody jsou mensi nez problematicnost implementace. PG neni threadova aplikace takze se pouziva sdilena pamet (IPC) a to je dost osemetna vec je nutne resit veci jako co delat kdyz tato pamet dojde apod. Z dlouhodobeho hlediska se doslo k tomu, ze radeji nez pouzivat pro podobne cache sdilene pameti tak radeji udelat persistentni servery (neco jako apache) ktere po ukonceni spojeni ziji dal a cekaji na dalsi session.

jsou rozhodne dobry napad, pokud jejich startovani zabere hodne casu. Spise by pomohly v pripadech, kdy se casto zakladaji nove db sessions. Uz vidim ten radek v postgres.conf:
spare_postmasters=2
Ale mozna by to byla skoro zbytecna prace - existuji demoni provozujici connection pooling, ty udrzi prislusny pocet postmasteru pri zivote. Nemam je ale prozkoumane.
Te sdilene cache pripravenych dotazu je, myslim, skoda...

Tohle se prece resi stored procedurama, to sou Microsofti SQL server a Oracle jediny db enginy co je maj? Nejenom ze resi problem kompilace a presistence execution planu, ale da se tim i docela dobre ohlidat bezpecnost, kod pracujici s databazi nema prava na nic jinyho nez na spousteni urcenych sprocs. Zadny prava na zmeny nebo mazani zaznamu v tabulkach, jen na spusteni procedur co to delaj (v teorii hlidane a bezpecne).

PostreSQL ma tyhlety veci v podstate taky, a docela dobre, i kdyz (zatim) bez featur jako jsou packages v Oraclu.
Stored procedures ale neresi napr. nasledujici scenar: Instance Apache se kazda pripojuji do db samostatne. Webova stranka je navrzena tak, aby v ni uzivatel mohl data prohlizet po strankach - to znamena, ze ruzne instance Apache spousteji identicke selecty, akorat s jinymi parametry. Nemyslim si, ze na tohle by bylo vhodne psat proceduru. Ten select muze byt vytvoren vicemene ad hoc, jenom se vi, ze ted se pravdepodobne bude nekolikrat opakovat v obecne ruznych db sessions.

No treba oracle to resi, tak, ze dotazy jsou perzistentni mezi sessions a muze je pouzivat i vice uzivatelu najednou. Oracle rozlisuje tzv. soft a hard parse. Soft parse vlastne akorat nalezne parsovany a optimalizovany dotaz ve sdilene pameti.

SP je neco, co je eventuelne vhodne pouzit v 'projektech'. Tedy ulohach, kde se sejdou preskoleni ucitele, jaderni fyzici, matematici a zemedelsti inzenyri a bastli mesice na ruznych SQL prikazech odpovidajice db-navrhu.

To co popisuje p. Zak cili vice na skupini lidi, kteri se snazi vyrabet softwarove produkty a neni jim cizi slovo modularita.

SP zrovna tak jako komplikovane SQL prikazy znamenaji totiz smrt modularity.

To by mne zajímalo proč? Naopak. Díky SP mohu provést ještě lepší dekompozici. Schopných programátorů jsem v Čechách moc neviděl, a je mi úplně jedno, co dělali. Zato bastlířů, ktěří všemu rozumněli a na všechno měli názor jsem viděl dost. Až na MySQL jsou si všechny db skorem rovny, pominu-li hiearch. dotazy atd. Netuším, proč by měl být komplikovany SQL dotaz narušovat modularitu aplikace. Jak to spolu souvisí?

netrivialni problemy (napr. kontrola schopnosti plnenei dodavky (=ability to deliver) v nejakem vyrobnim informacnim systemu je nutno realizovat pomoci komplikovaneho SQL prikazu. V tomto prikazu jsou schovany jaksi automaticky 'podprikazy' napr. pro zjistovani stavu na sklade. Modularni system ma pro zjistovani stavu na sklade vlastni funkci, ktera muze byt dokonce dodana externim dodavatelem.

Pro jiny informacni system, ktery pouziva jiny skladovy system, je zjistovani schopnosti realizovat dodavku stejne, vymeni se pouze ta zjistovaci funkce pro stav na sklade. U SQL systemu je nutno prekopat SQL prikazy. To NENI modularita.

Jenom prosim at nikdo nerika, ze by to slo pomoci SP. Pak musi totiz prozradit, jestli bude ta modularni SP pro skladovy stav ma byt pro informix 7.1, oracle 8.1.15 nebo kterou to db a jeji verzi. A co kdyz nekdo pouziva mysql?