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