AD Blog

Abych nezaplevelil již tak rozsáhlou diskuzi v anotaci zmíněném článku, pokusím se tady popsat jak jsem tento úkol řešil v roce 1993 v databázi Foxpro 2.

Pro mladší: Foxpro 2 je (byla) realační databáze v prostředí DOS, datový systém dbx (soubory typu dbf, co tabulka to soubor, co index to soubor atd.)

Jednalo se o poměrně rozsáhlou aplikaci nejmenované firmy, jejíž cílem bylo sledovat platby zákazníků. Bezpečnost dat tedy byla jedním ze základních předpokladů úspěšné implemetace. Dalším faktorem bylo, že požadavek zněl na sledování a archivaci všech změn v datech.

Vzhledem k množství různých tabulek jsem zvolil následující strategii:

Vytvořil jsem tabulku archiv s následujícími poli:

• id (integer – primární klíč tabulky)
• tabulka (char – jméno tabulky ve které byla změna)
• id_tabulka (integer – primární klíč změněného záznamu)
• zmenil (char – kdo provedl změnu, zalogovaný uživatel)
• kdy_zmenil (date – datum a čas změny)
• puvodni (memo /v mysql odpovídá tomuto typu text/ – původní hodnoty záznamu v CSV formátu – oddělovač byl tuším „;“)
• nove (memo – nové hodnoty záznamu v CSV formátu – oddělovač byl tuším „;“)

Pak zbývalo ošetřit okrajové podmínky:

• nový záznam – pole puvodni zůstalo prázdné
• smazání záznamu – pole nove zůstalo prázdné

Jak to fungovalo: v okamžiku kdy obsluha zadala pokyn k uložení dat, vygeneroval se záznam v archívu a naplnili se do něj data, pole puvodni z tabulky (nová data nebyla tam zatím uložena), pole novy z formuláře a nová data byla potom uložena do kmenové tabulky. To celé v rámci jedné transakce.

Jaké to mělo výhody:

• nezávislost na struktuře tabulky – do jednoho souboru se zapisovaly změny asi ze 40 tabulek v systému
• dokonalý přehled co, kdy a jak
• možnost zpětné rekonstrukce dat

A nevýhody:

• neustále bobtnající tabulka archiv
• určitá chybovost memo souboru ve Foxpro 2
• nepochybně větší zátěž sítě a serveru

No, třeba se to bude někomu hodit.