historie a jedinecnost [Re: Platnost zaznamu v ciselniku jeste jednou]

Radek Kanovsky rk na dat.cz
Čtvrtek Červenec 24 17:56:44 CEST 2003


On Thu, Jul 24, 2003 at 04:44:47PM +0200, Karel Zak wrote:

> > > Naopak se mne ted po obede jevi jednoduchy trigger jako nevyhovujici,
> > > protoze pravdepodobne bude potreba zamknout tabulku BEFORE a odemknout
> > > AFTER. Takovy cirkus uz je docela velka komplikace a lepsi bude to resit
> > > v aplikaci.
> 
> Ty same moznosti co ma aplikace ma i libovolna funkce uvnitr DB
> serveru...

Jo, jo, ale jak jsem psal, tak silne preferovana je flexibilita a
znovupouzitelnost. Snazim se schema databaze udrzovat co nejjednodussi,
protoze kazda specialita snizuje snadnost upravy komponenty. Pokud
by pouziti komponenty znamenalo hrabani se v SQL a preprogramovani
desitek triggeru, tak by takova komponenta okamzite ztratila na
pritazlivosti :-)

Navic mam obavu ze slozitejsich konstrukci nez je CREATE TABLE/INDEX,
protoze cokoliv slozitejsiho zpusobuje problemy pri upgradech a
restorech databaze. Nepamatuju si, kdy by pg_dump/pg_restore probehl
uplne bez asistence obsluhy :-(   7.3 uz ma myslim uvnitr nejaky graf
dependenci, tak se to snad zlepsi.

>  CREATE TABLE tab (data text);
> 
>  trans1: INSERT INTO tab VALUES ('aaa');
>  trans2: INSERT INTO tab VALUES ('aaa');
> 
>  nemelo by dojit k tomu, ze obe transakce uspesne zapisi stejna 
>  data do tabulky. IMHO to zase tak jednoduche jak se zdalo nebude :-(

Zatim se nejschudnejsi jevi zamykani tabulky. Mezi kontrolou a insertem
muzu ovsem jeste spoustet "aplikacni triggery", ktere mohou vyvolat
dalsi SQL dotazy a neni dopredu uplne jasne, jestli takovy zamek nebude
zpusobovat nejake nepekne deadlocky.

> Mozna by preci jen stalo za to premystet nad tim neslo-li by udelat s
> tech intervalu jeden unique index.

Platnosti jsou vedeny jako datum (nejmensi jednotka 1 den). Dost casto
budou mit zaznamy stejne platnosti. Nevim presne, co mate ted na mysli.

Navic mam takovy pocit, ze tu historii postgres vlastne z velke casti
resi uvnitr diky MultiVersion Concurrency Control. Ale nechce nam to dat
k dispozici :-)

> Ono ovlivnene radky by to slo snadno pomoci FOR UPDATE. Ale nove
> vlozeny radek uz FOR UPDATE nepozna. 

Prave.

Radek Kaňovský


Další informace o konferenci Databases