Unikátní index a hodnoty NULL

[Ing. Pavel PaJaSoft Janoušek]

	Zdravím,

	vyskytl se mi níže uvedený případ a chtěl bych se zeptat, zda-li to
má nějaké systémově čisté řešení.

	Představte si situaci, že máte jistou aplikaci která něco eviduje, a
která se vůči novým záznamům chová tak, že je nejprve někdo musí schválit (=
po schválení získá evidenční číslo apod.) a teprve pak je "vidět" v systému.
Položky takového záznamu jsou různé povahy, některé se berou z číselníků.
Pokud položka v číselníku neexistuje, doplní se nová, ale nikoli tak, že se
doplní do tabulky s konkrétním číselníkem, ale samozřejmě stejně jako záznam
podléhá schválení... - schvalovač může klidně přidání nového záznamu do
číselníku zamítnout, ale kdyby to bylo v jedné tabulce, tak by se tato "nově
nechtěně" přidaná položka číselníku mohla začít regulérně používát a už by z
jiných integritních důvodů nešla odstranit = do okamžiku schválení nebude a
nesmí být v číselníku.

	Toliko v krátkosti "bussiness stav". Řešení, které mi připadá vcelku
stadndardní a čisté je mít pro nejelementárnější případ (evidence záznamů,
evidence návrhů a jeden číselník) 3 tabulky:

- tabulka "ostrých" záznamů
- tabulka návrhů
- tabulka s číselníkem

	Integritní omezení jsou definovaný pomocí DDL maximalisticky - tedy
vše, co lze popsat via DDL SQL je rovněž popsáno (typicky zabránění smazání
položky číselníku, pokud je použita v ostrých záznamech, všechny integritní
vazby,  všechny logická omezení pro nové záznamy apod.)

	Problém se mi vyskytl s tabulkou návrhů. Představoval jsem si ji
tak, že jednoduše bude mít nějakou takovou strukturu:

- id návrhu
- ID položky číselníku nebo NULL
- text nové položky číselníku nebo NULL

	Zároveň je definováno tabulkové omezení, které říká, že TRUE je
pouze (ID položky číselníku je NULL a je smysluplně vyplněn text nové
položky číselníku) NEBO (ID položky není NULL a pak návrh nové položky je
NULL).

	Tak - to by bylo OK a myslím si, že i formálně databázově čisté.
Ovšem chci-li definovat další tabulkové omezení a sice takové, že je z
hlediska systému docela nesmysl, aby se v tabulce návrhů vyskytovaly
DUPLICITNÍ návrhy jsem v háji. Jde o to, že sice pomocí BTREE (nic jiného ty
podmínky nepodporuje) mohu udělat unikátní index přes (ID položky, text
návrhu), problém je, že VŠECHNY vložené záznamy odpovídající tabulkovému
omezení (CHECK) budou z hlediska indexu VŽDY unikátní...

Mohu milionkrát vložit, že ID je NULL a text je "Pepa", stejně tak, že ID=20
a text je NULL (ID=20, text je "pepa" vložit nejde z důvodu tabulkové
kontroly) a to je problém, jehož řešení neznám a chtěl bych...

	Jediné co mne napadá je implementačně závislé na PostgreSQL (použita
je verze 8.0.3) použití RULES pro INSERT/UPDATE a ve vlastní režii
prozkoumat, zda-li se záznam stejného obsahu z logického hlediska v systému
nevyskytuje.

	Stejně tak jako je pro referenční integritu a hodnoty NULL
definováno v SQL standardu 3 typy porovnání - vychozí,  MATCH FULL a MATCH
PARTIAL, říkám si, že by tam také mohlo být řešeno toto, leč jsem to nikde
nenašel.

	Šel jsem na problém špatně (z hlediska databází) nebo jen toto
skutečně nejde definovat a je třeba hlídat na aplikační úrovní, případně na
DB úrovni, ale pomocí implementačně závislých prvků?

	Dík za každý tip.

-------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)             FoNet, spol. s r. o.
Technicka podpora, Intranet/Internet     Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz         Tel.: +420  5  4324 4749
WWW:    http://WWW.FoNet.Cz/           E-mail: mailto:Info na FoNet.Cz
-------------------------------------------------------------------