Unikátní identifikace

Každý z Vás již asi narazil na aplikaci, kdy data nejsou na jednom místě a je třeba je shromažďovat v nějaké centrální evidenci. Typickým příkladem může být například aplikace pro tvorbu cenových nabídek, kterou budou používat jak obchodní zástupci určité společnosti, tak zároveň v této společnosti potřebují mít přehled o nabídkách a musí mít možnost přípravy dat pro zástupce.

V podstatě se dá říci, že na firmě připraví data (číselníky produktů, jejich kategorizaci, rozmezí prodejních cen atd.), obchodní zástupce si je "nahraje" na svůj notebook a vyrazí na cesty. Za nějakou dobu se vrátí na firmu a potřebuje jím vytvořené nabídky dostat do databáze firemní server, aby se uživatelé na firmě mohli podívat za kolik kde co nabídnul. Celkem je asi zřejmé, že takovýchto obchodních zástupců může mít firma více a rovněž i přímo na firmě při jednání mohou vznikat cenové nabídky.

Každý byste pravděpodobně logiku aplikace řešil jinak, určitě by Vás napadlo nějaké řešení. Já se Vám pokusím nabídnout cestu, která se zase tak moc od běžné práci s daty neliší.

Předpokládejme, že data budou na MSDE nebo MS SQL Serveru (z mnoha důvodů - síťová aplikace, zabezpečení atd.) a rovněž i obchodní zástupci budou mít na svém notebooku MS SQL server (MSDE). Čili, úkolem pak bude "sesynchronizovat" dvě databáze.

Obchodní zástupci dostanou připravená data od firmy a do jejich editace nebudou mít přístup - produkty atd. Co ale může každý zástupce je změna a přidávání záznamů v Adresáři a samozřejmě tvorba nabídek. Při "klasické" metodě identifikace záznamů pomocí IDENTITY vlastností polí bigint (toto je popsáno v jiném seriálu) už na první pohled je každému jasné, že se mi může vrátit několik zástupců s firmou, která bude pokaždé jiná ale budou mít shodné číslo, a totéž se může stát u nabídek. Nabídka je obecně složena z hlavičky a položek, což jsou dvě tabulky. V tabulce s hlavičkou je uložen identifikátor firmy, u každého záznamu s položkou nabídky je uložen identifikátor hlavičky nabídky, abychom pak byli schopni nabídku sestavit v nějaké rozumné formě. Pokud budou identifikátory vycházet z IDENTITY čísel, pak se celkem bez problémů při kopírování na firemní server nabídky a firmy potkají a bude těžkej zmatek. Což je velmi zjednodušeně řečeno, protože ve skutečnosti buď dostanou při svém uložení nové ID a tím pádem ztratí integritu, anebo když vypnete automatické generování ID tak někde dojde k pokusu o uložení duplicitní hodnoty do primárního klíče a aplikace zavěsí.

Tento problém se nechá obejít tak, že sice nadále budeme využívat generovaných IDENTITY ukazatelů, ať už pro vlastní editaci jednotlivých záznamů anebo jenom z piety :) (i když ne jenom proto - osvětlím později), ale k tabulkám, kde hrozí, že se jejich hodnoty budou potkávat, si přidáme sloupec s unikátním identifikátorem.

  Další

Autor: The Bozena