Platnost zaznamu v ciselniku jeste jednou

"Zíka Aleš, Ing." Ales.Zika na pel.br.ds.mfcr.cz
Pondělí Červenec 21 11:51:44 CEST 2003


> > 	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.
> 
>  Nebylo v te debate take receno, ze PK je vetsinou unikatni 
> generovane 
>  cislo (sequence/autoincrement)? Asi by pomohla nejaka ukazka vasich
>  tabulek.
> 
>     Karel


	To ano, ale jde o to, ze jde porad o stejneho zakaznika, jen se mu
zmenil nektery udaj (Tel.c., adresa) a ja potrebuji:
	1. Identifikovat konkretni "verzi" udaju pro dany pripad, treba aby
se pri tisku opisu dva roky stare faktury pouzily tehdy platne udaje a ne
soucasne.
	2. Identifikovat vsechny "verze" jednoho zakaznika jako jeden celek,
napr. pro statistiky tapu "kolik kdo nakoupil za poslednich pet let".


	Pokusim se se zverejnit zjednodusene verze svych tabulek a popsat
problem, ve skutecnosti nejde o faktury a zakazniky, ale o zavodniky a
vysledky zavodu, ale princip je stejny, jen jsem se snazil pouzit model,
ktery je vetsine asi blizsi:

CREATE TABLE zavodnik (
   zavodnik SERIAL PRIMARY KEY,
   zavodnik_vazba INT,
   registracni_cislo NUMERIC (10,0),
   prijmeni TEXT,
   jmeno TEXT,
   datum_narozeni DATE,
   vt VARCHAR(2) REFERENCES vt ON DELETE RESTRICT ON UPDATE CASCADE, 
   oddil CHAR (3) REFERENCES oddil ON DELETE RESTRICT ON UPDATE CASCADE,
   stat CHAR (3) REFERENCES stat ON DELETE RESTRICT ON UPDATE CASCADE
);

CREATE TABLE startovka (
   zavod INT REFERENCES zavod ON DELETE RESTRICT ON UPDATE CASCADE,
   zavodnik INT REFERENCES zavodnik ON DELETE RESTRICT ON UPDATE CASCADE,
   stc NUMERIC(3) NOT NULL,
   cas INTERVAL,
   poradi INT,
   zebrickove_body INT,
 PRIMARY KEY (zavod, zavodnik)
);

CREATE TABLE zebricek (
   zavodnik INT PRIMARY KEY REFERENCES zavodnik ON DELETE RESTRICT ON UPDATE
CASCADE,	
   celkove_body INT,
   poradi INT,
);

	Cele je to vyrazne zjednodusene - zavodici posadka se  muze skladat
z vice zavodniku, z jednoho zavodu se muze pocitat vice bodu pro ruzne
zebricky, takze ve skutecnosti je to rozsekano do vice tabulek, ale princip
zustava.
	Mam ciselnik zavodniku (zavodnik), ze ktereho se pro kazdy
jednotlivy zavod sestavuje startovni listina (startovka), zavodnik si vyjede
nejake poradi a podle nej ziska body do zebricku. Na konci sezony se podle
nejakeho algoritmu spocitaji celkove body (vetsinou je to soucet, nejhorsi
zavod se skrta) a zavodnik tak ziska poradi v zebricku za danou sezonu.

	Muze se stat, ze se v prubehu sezony udaje o zavodnikovi zmeni -
vyjede si lepsi VT (vykonnostni tridu), holka se vda... Pritom je potreba,
aby se mi zavody pred změnou zobrazovaly se starymi udaji, protoze treba
prave VT ovlivnuje vypocet zebrickovych bodu. Takze momentalne to resim tak,
ze zalozim to tabulky zavodnik novy zaznam s novou hodnoutou atributu
zavodnik a startovka pro kazdy zavod odkazuje na zaznam, ktery byl platny v
dobe jeho konani (ja ho oznacuji "verze zavodnika").

	Problem nastava s celkovym zebrickem, pokud by se ridil jen podle
atributu zavodnik, rozpadli by se zavodnikci, u kterych doslo v prubehu
sezony ke zmene, na dva (nebo i vice) a kazdy by mel zapoctenou jen cast
sezony.
	Momentalne to resim atributem zavodnik_vazba v tabulce zavodnici,
ktery se pri zakladani uplne noveho zavodnika naplni hodnotou z pole
zavodnik, ale pri vytvareni dalsich "verzi" se uz nemeni a tak identifikuje,
ktere zaznamy patri k sobe a jsou to jen ruzne "verze" jednoho zavodnika.
	Takze vypocet zebricku je momentalne pomerne komplikovany postup,
kdy podle atributu zavodnik z tabulky rebricek zjistim v tabulce zavodnik
hodnotu pole zavodnik_vazba, z teze tabulky pak vyberu vsechny zaznamy se
stejnou hodnotou tohoto a pole a ziskam tak seznam hodnot pro pole zavodnik
a ty pak hledam v tabulce startovka. Prvni krok bych si mohl usetrit, kdyby
mel v tabulce zebricek pole zavodnik_vazba misto zavodnik, ale tam uz zase
pro RI nemuzu pouzit REFERENCES, protoze neni unikatni.

	Myslel jsem, jestli bych si nepomohl zavedenim systemu od-do, kdy by
kazdy zavodnik mel jedno stejne jedinecne ID od narozeni az do smrti, ale
zatim mi to tak ani moc nepripada. Zjednodusim si vypocet zebricku a
zkomplikuji hlidani RI u startovky.

	Ma nekdo nejaky jiny napad?


	Diky,

			Ales Zika
			ČSE Spoje Pelhřimov

			http://results.cz
			e-mail: Ales.Zika na pel.br.ds.mfcr.cz
				  Ales.Zika na seznam.cz


Další informace o konferenci Test