A proc by nemohli .... my je s uspechem pouzivame a jsme spokojeni ... :-)
Vladimír Náprstek napsal(a): > Tyhle logy stejne nemuzou slouzit k dohledani stavu DB. Je to jen to tom > co se kdy zmenilo nebo spis kdo to byl. Proste historie a nic vic... > > Jiří Mareš píše v Út 19. 12. 2006 v 12:37 +0100: >> My pouzivame totez, ale pro lepsi dohledavani zmen (docela casta operace) >> mame pro kazdy auditovanou tablku >> (neauditujeme vsechny) specialni audit tabulku, kde co radek to zmena, ma to >> platnost od-do (tim se hodne zjednodusi >> dohledavani jak db vypadala napr. 20.12.2006 12:30) .. >> >> Rekl bych, ze hodne moc zalezi co od toho budete do budoucna chtit ... >> >> Vladimír Náprstek napsal(a): >>> U jedne nasi "velke" aplikace je tento problem resen tak, ze aplikace do >>> jedne specialni tabulky strka veskere auditovaci informace: >>> >>> datum, uzivatel, kde, co, nova hodnota, atd. >>> >>> jen najit puvodni hodnotu musite trochu sloziteji, protoze puvodni >>> hodnota je v jinem radku (jako nova hodnota ve starsim zaznamu). Je to >>> velmi jednoduche, vse mate na jednom miste. Jen na to nedavejte indexy, >>> protoze pri vetsim mnozstvi zapisu nebude db delat nic jineho nez ty >>> indexy obnovovat... >>> >>> >>> Petr Ferschmann píše v Út 19. 12. 2006 v 09:49 +0100: >>>> Zdravím, >>>> >>>> my jsme toto řešili na dvou projektech takto: >>>> - hibernate pro to má podporu. Nicméně některé věci tam jsou >>>> složitější. Je možné získat předchozí a novou hodnotu. Ale např. u >>>> vazby N ku N je to docela těžší. Pokud budete mít zájem o kód rád >>>> zveřejním. >>>> >>>> - u jedno jsme používali Oracle. Oracle má sice nějakou podporu pro >>>> auditování (myslím, že Audit Trail), ale my jsme stejně použili >>>> triggery. >>>> -- Jiří Mareš (mailto:[EMAIL PROTECTED]) ČSAD SVT Praha, s.r.o. (http://www.svt.cz) Czech Republic
