Не съм сигурен, че има един „най-добър подход“, има толкова много променливи, които трябва да се вземат предвид, включително колко далеч сте по пътя на развитие.
След като преминах през базирани на код и решения за одит на db-тригери, изброих някои коментари по-долу; Надявам се, че можете да видите къде се намирате в момента (по отношение на развитието) може да повлияе на тези проблеми:
- Ако трябва да картографирате потребителя, който е променил данните (което обикновено правите), тогава тригерите на db ще трябва по някакъв начин да получат тази информация. Не е невъзможно, но повече работа и няколко начина за подход към това (заявка, изпълняваща потребител от db, колона за общ потребител във всяка таблица и т.н.)
- Ако използвате тригери за db и разчитате на броя на засегнатите редове, върнати от заявки, тогава вашите одитни задействания трябва да имат това изключено или съществуващият ви код да бъде променен, за да ги отчита.
- IMHO db тригерите предлагат повече сигурност и предлагат по-лесен път към автоматизация на одита, но те не са сигурни, тъй като всеки с подходящ достъп може да деактивира тригерите, да промени данните и след това да ги активира отново. С други думи, уверете се, че вашите права за достъп до сигурността на db са строги.
- Наличието на една таблица за история не е лош начин, въпреки че ще имате повече работа за вършене (и данни за съхранение), ако одитирате историята за множество таблици, особено когато става въпрос за реконструкция на одитната пътека. Трябва също да помислите за проблеми със заключването, ако има много таблици, които се опитват да запишат в една таблица за одит.
- Имането на таблица с хронология на одита за всяка таблица е друга опция. Просто трябва всяка колона в таблицата за одит да бъде нула, както и да съхранява датата и часа на действието (вмъкване/актуализиране/изтриване) и потребителя, свързан с действието.
- Ако изберете опцията за единична таблица, освен ако нямате много време за това, не се опитвайте да правите одит само на актуализации или изтривания, въпреки че може да е изкушаващо да избягвате вмъквания (тъй като повечето приложенията правят това по-често от актуализациите или изтриванията), реконструирането на хронологията на одита отнема доста работа.
- Ако вашите сървъри или данни обхващат множество часови зони, тогава помислете за използването на подходящ тип дата и час, за да можете да съхранявате и реконструирате времевата линия, т.е. да съхранявате датата на одитното събитие в UTC, както и да включите изместването на часовата зона.
- Тези одитни таблици могат да станат огромни, така че имайте стратегия, ако започнат да влияят на ефективността. Опциите включват разделяне на таблицата на различни дискове, архивиране и т.н. Основно мислете за това сега, а не когато стане проблем :)
