Where should IsChanged functionality be handled?

Question

I'm having an internal debate about where I should handle checking for changes to data and can't decide on the practice that makes the most sense:

1. Handling IsChanged in the GUI - This requires persistence of data between page load and posting of data which is potentially a lot of bandwidth/page delivery overhead. This isn't so bad in a win forms application, but in a website, this could start having a major financial impact for bandwidth costs.
2. Handling it in the DAL - This requires multiple calls to the database to check if any data has changed prior to saving it. This potentially means an extra needless call to the database potentially causing scalability issues by needless database queries.
3. Handling it in a Save() stored proc - This would require the stored proc to potentially make an extra needless call to the table to check, but would save the extra call from the DAL to the database. This could potentially scale better than having the DAL handle it, but my gut says this can be done better.
4. Handling it in a trigger - This would require using a trigger (which I'm emotionally averse to, I tend to avoid triggers except where absolutely necessary).
5. Don't handle IsChanged functionality at all - It not only becomes hard to handle the "LastUpdated" date, but saving data unnecessarily to the database seems like a bad practice for scalability in itself.

So each approach has its drawbacks and I'm at a loss as to which is the best of this bad bunch. Does anyone have any more scalable ideas for handling data persistence for the specific purpose of seeing if anything has changed?

Architecture: SQL Server 2005, ASP.NET MVC, IIS7, High scalability requirements for non-specific global audience.

Answer 1

I handle it in the DAL - it has the original values in it so no need to go to the database.

Answer 2

For each entity in your system introduce additional Version field. With this field you will be able to check for changes at the database level.

Since you have a web application and usually scalability matters for web application, I would suggest you to avoid IsChanged logic at the UI level. LastUpdated date can be set at the database level during Save operation.

Answer 3

Okay, here's another solution - I've not thought through all the repercussions, but it could work I think:

Think about the GetHashCode() comparison functionality:

At page load time, you calculate the hash code for your page data. You store the hashcode in the page data or viewstate/session if that's what you prefer.

At data post (postback) you calculate the hash code of the data that was posted and compare it to the original hash. If it's different, the user changed something and you can save it back to the database.

• Pros
  • You don't have to store all your original data in the page load which cuts down on bandwidth/page delivery overhead.
  • You don't have to have your DAL do multiple calls to the database to determine if something's changed.
  • The record will only be updated in the database if something's changed and hence maintain your correct LastUpdated date.
• Cons
  • You still have to load any original data from the database into your business object that wasn't stored in the "viewstate" that is necessary to save a valid record to your database.
  • Change of one field will change the hash, but you don't know which field unless you call the original data from the database to compare. On a side note, perhaps you don't need to. If you've gotta update any of the fields the timestamp changes and overwriting a field that hasn't changed for all intensive purposes doesn't have any effect.
  • You can't completely rule out the chance of collisions but they would be rare. This comes down to is the repercussion of a collision acceptable or not?
• Either/Or
  • If you store the hash in the session, then that saves bandwidth, but increases server resources so you have a potential scalability issue in either case to consider.
• Unknowns
  • Is the overhead of updating a single column and different than that of updating multiple/all columns in a record? I don't know what that performance overhead is.