Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Database & SysAdmin
  3. Database
  4. Strategies for auditing table records

Strategies for auditing table records

Scheduled Pinned Locked Moved Database
4 Posts 3 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • K Offline
    K Offline
    Keith Andersch
    wrote on last edited by
    #1

    Hi all. I'm wondering if any of you would know of any articles and/or books regarding ways to keep track of who's been entering a particular record, modifying it, etc. I'm working on something right now that I would like to have something like it in place. I can think of putting a couple of fields, last_modified_by and date_of_mod, into each table which see the need for tracking, but that seems clunky. It would work well enough for this project as only a few people will be using it and it's not very big but when I start getting into the bigger stuff, I'm sure that will break down. So, if anybody knows of any good references, please, send it along. Thanks, Keith

    P S 2 Replies Last reply
    0
    • K Keith Andersch

      Hi all. I'm wondering if any of you would know of any articles and/or books regarding ways to keep track of who's been entering a particular record, modifying it, etc. I'm working on something right now that I would like to have something like it in place. I can think of putting a couple of fields, last_modified_by and date_of_mod, into each table which see the need for tracking, but that seems clunky. It would work well enough for this project as only a few people will be using it and it's not very big but when I start getting into the bigger stuff, I'm sure that will break down. So, if anybody knows of any good references, please, send it along. Thanks, Keith

      P Offline
      P Offline
      Paul Conrad
      wrote on last edited by
      #2

      Keith Andersch wrote:

      I can think of putting a couple of fields, last_modified_by and date_of_mod, into each table which see the need for tracking, but that seems clunky. It would work well enough for this project as only a few people will be using it and it's not very big but when I start getting into the bigger stuff, I'm sure that will break down

      That is a start. I don't see why it would be an issue when you add more users to the system would be a problem, though. You might want to have a separate table for keeping the audit trail rather than adding fields to the existing tables.

      1 Reply Last reply
      0
      • K Keith Andersch

        Hi all. I'm wondering if any of you would know of any articles and/or books regarding ways to keep track of who's been entering a particular record, modifying it, etc. I'm working on something right now that I would like to have something like it in place. I can think of putting a couple of fields, last_modified_by and date_of_mod, into each table which see the need for tracking, but that seems clunky. It would work well enough for this project as only a few people will be using it and it's not very big but when I start getting into the bigger stuff, I'm sure that will break down. So, if anybody knows of any good references, please, send it along. Thanks, Keith

        S Offline
        S Offline
        Scott Serl
        wrote on last edited by
        #3

        I have seen and used that strategy in many projects and it generally works well. On projects that require closer auditing, I use triggers to log changes to another database. That way, even admins changes through queries are logged. The data generated by this method is heavily taxing on database resources and may not scale well to very high transaction volumes (only load tests can show the truth). Scott

        P 1 Reply Last reply
        0
        • S Scott Serl

          I have seen and used that strategy in many projects and it generally works well. On projects that require closer auditing, I use triggers to log changes to another database. That way, even admins changes through queries are logged. The data generated by this method is heavily taxing on database resources and may not scale well to very high transaction volumes (only load tests can show the truth). Scott

          P Offline
          P Offline
          Paul Conrad
          wrote on last edited by
          #4

          Scott Serl wrote:

          On projects that require closer auditing, I use triggers to log changes to another database. That way, even admins changes through queries are logged.

          Excellent point :-D

          1 Reply Last reply
          0
          Reply
          • Reply as topic
          Log in to reply
          • Oldest to Newest
          • Newest to Oldest
          • Most Votes


          • Login

          • Don't have an account? Register

          • Login or register to search.
          • First post
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • World
          • Users
          • Groups