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. > >> > -- S pozdravem ----------------- Vladimír Náprstek specialista AKC RWE Energy Customer Services tel: 475 233 102 e-mail: [EMAIL PROTECTED]
