Post reply

Audit systems: a good idea or a mess to maintain?

  • March 1, 2018 at 7:36 am

    #1981628

    peter.midgley - Thursday, March 1, 2018 2:06 AM

    William Rayer - Thursday, March 1, 2018 1:27 AM

    There is absolutely no need to ever audit INSERTs. All they do is double the storage requirements. If you INSERT a row and never change it, the original row is in both the original table and the audit table. Instant duplication of data and audit tables get large enough without that guaranteed duplication of data.

    If you don't audit the first INSERT, how do you know who inserted the row or when it was inserted? The only way I could think of doing this is by adding extra columns to the original table.

    what I said !!!

    Yep... strongly agree with both of you on that.  My statement was talking about only what ended up in the audit table but may not have come across that way.

    --Jeff Moden

    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • March 1, 2018 at 8:26 am

    #1981635

    If we're talking about DML auditing, then Change Tracking can potentially give you what you need with less overhead and storage than insert / delete triggers.

    "Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Viewing 2 posts - 16 through 16 (of 16 total)

You must be logged in to reply to this topic. Login to reply