Platnost zaznamu v ciselniku jeste jednou

[Michal Kubecek]

On Mon, Jul 21, 2003 at 11:30:42AM +0200, Karel Zak wrote:
> 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.).

Permanentní údaje jsou v CUSTOMER_IDENTITIES, (potenciálně) proměnné
v CUSTOMERS. Jenže v praxi těch skutečně neměnných údajů moc není. Jméno
i příjmení se může změnit, rodné číslo bohužel také, možná i IČO (Co když
přestanu podnikat a za dva roky zase začnu? Dostanu opět stejné IČO jako
minule?).

>  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.

Asi jsem dost jasně neoddělil první variantu od druhé. Ve druhé variantě
(které dávám přednost) mají obě tabulky jako primární klíč pouze ID a
CUSTOMER_IDENTITIES slouží k identifikaci, které položky CUSTOMERS
popisují téhož zákazníka v různých obdobích. To první řešení jsem zmínil
jen jako příklad, jak se to syntakticky zapíše.

> > 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.

Pokud jediné, k čemu ty informace potřebuji, je to, abych mohl vytisknout
duplikát dva roky staré faktury nebo identifikovat zákazníka při kontrole,
bude to stačit. Pro složitější práci to samozřejmě moc praktické není.

                                                           Michal Kubeček