Platnost zaznamu v ciselniku jeste jednou
Karel Zak
zakkr na zf.jcu.cz
Pondělí Červenec 21 11:30:42 CEST 2003
On Mon, Jul 21, 2003 at 10:07:48AM +0200, Michal Kubecek wrote:
> On Mon, Jul 21, 2003 at 07:37:04AM +0200, "Zíka Aleš, Ing." wrote:
>
> > Trochu jsem si s tim hral a vyvstaly mi dalsi dotazy:
> > Když to takhle udelam, nemuze byt uz PK jen cislo zakaznika, protoze
> > se v tabulce vyskytuje vicekrat, ale musim PK nejak poslepovat z cisla
> > zakaznika + atributu od - do.
> > Druhy problem mam s RI. Protoze cislo zakaznika uz neni unikatni
> > atribut, nelze na nej referencovat cizi klic tabulky faktur, aspon ne
> > standardni klauzuli FOREIGN KEY ... REFERENCES.
>
> create table CUSTOMERS (
> ID integer not null,
> VALID_SINCE timestamp not null,
> VALID_UNTIL timestamp default null,
> ...
> primary key (ID,VALID_SINCE)
> );
>
> create table DOCUMENTS (
> ID integer not null primary key,
> ...
> CUSTOMER integer,
> CUSTOMER_VS timestamp,
> foreign key (CUSTOMER,CUSTOMER_VS) references CUSTOMERS(ID,VALID_SINCE)
> );
>
> Moc šťastné to ale není. Osobně to dělám tak, že mám dvě tabulky CUSTOMERS
> a CUSTOMER_IDENTITIES. V každé je normálně integer ID jako primární klíč.
> V tabulce CUSTOMERS jsou jednotlivé instance zákazníků (s časově omezenou
> platností) a v CUSTOMER_IDENTITIES jsou zákazníci jako takoví. Každý záznam
> v CUSTOMERS má položku IDENTITY, což je odkaz na odpovídající položku
> v CUSTOMER_IDENTITIES.
Mozna by stalo za to polozit si otazku ceho se SINCE/UNTIL tyka. IMHO
se ne vzdy tyka uplne celeho zakaznika, ale napriklad jen jeho adresy
apod. Pak by mozna stalo za to udrzovat separatne v dalsich tabulkach
tyto udaje u kterych dochazi ke zmenam. Bylo to tu debatovano a je to
ten model s hodne kosatou DB kde je tabulka temer na vsechno :-)
Podle mne to co popisuje vas datovy model neni moc presne, protoze vas
zakaznik je z hlediska historie definovan jen nejakym generovanym cislem.
Coz ve skutecnem zivote neni a to, ze se jedna o tehoz zakaznika
vetsinou popisije nejaka vetsi skupina z casoveho hlediska nemennych
dat (ICO, RC, otis prstu apod.).
IMHO tu validitu do klicu strkat nemusite. Kompletace k sobe
patricich udaju stejne bude provedena az selectem kterym budete zadat
o data. Jedine riziko takoveho reseni je, ze nekdo muze pridat
dokument k jiz nevalidnimu zakaznikovy coz muze je-li to pro vas
velky problem osetrit v aplikaci (hmm..) nebo nejlepe triggerem, ktery
bude kontrolovat je-li napriklad cas vytvoreni dokumentu v intervalu
since-until pozadovaneho (PK) zakaznika. Myslim, ze je to kompromis
lepsi nez takove PK/FK a s mina spojene problemy.
> Jiná možnost (ne moc elegantní, ale funkční) je jít cestou nejmenšího odporu
> a ke každé faktuře zkopírovat podstatné aktuální údaje zákazníka v okamžiku,
> kdy byla vystavena.
To muze byt dobre pro nejaky archiv, ale tezko s tim muzete ve vetsi
mire pracovat.
--
Karel Zak <zakkr na zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/
Další informace o konferenci Test