Re: Insert/Update/Delete Tracking.
From: Aaron [SQL Server MVP] (ten.xoc_at_dnartreb.noraa)
Date: 06/29/04
- Next message: Henok: "very very stange SP problem, please help"
- Previous message: Sean: "Re: Copying SQL Server table programmatically"
- In reply to: Jim Housern: "Insert/Update/Delete Tracking."
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 29 Jun 2004 17:33:38 -0400
> 1. Triggers on all tables that writes to an audit table - What kind of
performance hit does this have on databases?
Depends on your volume, usage, hardware, etc. No "single answer" exists.
You will need to test it to determine if the performance is acceptable in
your exact environment.
> Can I track who made the change easily?
Depends on your authentication mode. If you require window authentication,
then you can capture this information easily. If everyone shares a SQL
Server login, then no, you will not be able to tell bob from fred because
they both authenticated as app_user.
> Can I track what was changed easily?
Yes. See http://www.aspfaq.com/2448 for some rough ideas.
> What kind of performance hit would this have on the system? Is this
better then Triggers?
In my experience, Profiler is a HUGE performance drain, but it really
depends on what you are doing. Again, there is no magic answer other than
to test it and compare.
> Any other suggestions would be helpful...or if you could point me to a
place I can research this more.
Rather than re-invent the wheel, why don't you just buy a third-party
package? The time and development resources you would have spent otherwise
will easily outweigh the one-time cost of a package.
-- http://www.aspfaq.com/ (Reverse address to reply.)
- Next message: Henok: "very very stange SP problem, please help"
- Previous message: Sean: "Re: Copying SQL Server table programmatically"
- In reply to: Jim Housern: "Insert/Update/Delete Tracking."
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|