Logování vechDMLpříkazů v PostgreSQL?

[Ing. Pavel PaJaSoft Janousek]

Milan Zamazal wrote:
>     >> Dokazovat, kdo způsobil chybu.
> 
>     IPPJ>       A nevedete zurnal o operacich, kdyz je to tak kriticke
>     IPPJ> (samozrejme podporeny transkcemi)? - Samozrejme je to nutno na
>     IPPJ> aplikacni urovni, osobne nevidim duvod, proc by to (ani na
>     IPPJ> vyzadani) mel resit databazovy stroj.
> 
> O řešení na aplikační úrovni, tj. že k databázi bude přístup pouze přes
> speciální serverovou aplikaci, uvažuji.  To je ovšem značně netriviální,
> zejména z hlediska bezpečnosti a robustnosti.  Právě to byl cíl mého
> dotazu -- tomuto řešení se pokusit vyhnout, díky využití nějakého
> dostatečně jednoduchého mechanismu na serveru.
> 
> Obecně je výhodnější, když server (nebo knihovny, tam kde to má smysl)
> nabízí pokročilé standardní prostředky, než si vše psát sám.  Například
> využití RULEs může *velmi* odlehčit aplikačnímu kódu.

	Chapu, ze na jedne strane chcete odlehcit datastoru a na stranu druhou
mu prenechat maximum prace, ktera je zrejme optimalizovana a bude
odvedena rychleji nez vase 'pokusy'... (me badani a snazeni smeruje vzdy
timto smerem rovnez... proto napr. stored procedury a ne tahani dat
selecty pres JDBC, empiricky overeno u PostgreSQL a Sybase)

	Nicmene si myslim, ze 3-stupnovy (vrstvy) model je velmi bezne schema
(byt drazsi nez dvoustupnovy) a to s radou vyhod, ale i nejakym tim
omezeni. Tak jako se bezne nepozastavujete nad 3-stupnovym modelem u Web
aplikaci (1. stupen Vas klient s WWW rozhrannim, 2. stupen WWW
server/servlety apod., 3. stupen databaze), nevidim duvod, proc by 1.
stupen nemohl byt nahrazen tenkym klientem (ktery muze byt efektivnejsi
nez WWW rozhranni) a 2. stupen misto servletu bude obsahovat serverovou
aplikaci ci nejaky middle-ware/framework... 3. stupen zustane zachovan.
Ono to ma i tu vyhodu, ze 2. stupen muze zustat zachovan a WWW rozhranni
(pokud bude zadouci) muze byt jednoduse doplneno ve forme servletu,
ktere komunikuji se serverovou casti (tedy v podstate 4-stupnovy model).

	Rozhodne si vsak serverovou cast nepredstavuju jako soubor funkci nebo
knihovnu...

	A znovu opakuji - je treba si ujasnit, k cemu slouzi a jake ukoly
resi/ma resit relacni databaze. Pak nejsou na miste zklamani a rozpaky,
ze neco neresi - dnesni PostgreSQL, FireBird, Oracle apod. resi i veci,
ktere si myslim, ze by resit nemely, ale je to 'libive' z komercniho
hlediska...

>     IPPJ>       A nejsou lepsi replikace? PostgreSQL 8.0, ktery to ma
>     IPPJ> mit built-in jeste neni, ale projekt existuje davno a myslim,
>     IPPJ> ze pouzitelnost je velka - odkaz najdete na technologicke
>     IPPJ> stranke v domene postgresql.org.
> 
> Replikace by byly pro tu jednu polovinu mého problému úplně nejlepší,
> nebylo mi však známo že pro PostgreSQL existují, děkuji za upozornění.
> Nevíte, jsou-li s tím nějaké pozitivní nebo negativní zkušenosti?  Na
> základě svých zkušeností jsem k pokročilým rysům PostgreSQL dost
> skeptický, dokud nejsou pořádně odladěny.  Pokud by to mělo ohrozit
> robustnost serveru, tak raději použiji to aplikační řešení.

	Ja jsem rovnez spise konzervativni k modnim vykrikum. Co se tyce
PostgreSQL a replikaci, mam jednu pozitivni referenci, ze je to dobre,
kupodivu to i korektne funguje v realne zatezi, zaznamenal jsem spise
postesk v oblasti srovnani s MS SQL serverem 2000, ktery ma v teto
oblasti bohatejsi moznosti... Nicmene co je deklarovano udajne funguje
bez problemu. Osobni zkusenost to vsak neni.

	Navic mne napada, pokud alespon cast Vasich dat ma charakter Adresarove
sluzby, co nepremyslet o LDAP, to ma replikace primo v zakladnim popisu
prace...

PS: Vim, ze PostgreSQL ma i sva omezeni, nicmene jiz dlouho jsem nenasel
projekt, jehoz vhodnost pro PostgreSQL bych musel peclive vazit...
(samozrejme, ze ta vhodnost je spise opacna - tedy nasazeni PostgreSQL v
urcitem prostredi, aby mne nekdo nechytl za slovo).

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------