views:

227

answers:

3

Hi,

I didn't really know how to formulate the title. But this is my problem. We are using SqlCacheDependencies to update out cache objects. But the query behind this is "complicated" that we would like to make it somewhat easier.

Our first thought was to add a fieldname like DateChanged and use the DateChanged to check if an object has actually changed in stead of loading all the columns of a table.

SELECT DateChanged FROM Table1

in stead of

SELECT Id, Title, DateChanged, Description FROM Table1

But I was hoping someone could tell me if there are other ways to do this or if there are standards for naming the column that indicates a change. How are frameworks like "Entity framework" or "NHibernate" handle this?

Kind Regards, Sem

+1  A: 

It's usually called " timestamp"

ie in

Julian de Wit
+1  A: 

These are the columns I use on "auditable" entities:

version: hibernate's optimistic concurrency control
createdBy: FK to users
modifiedBy: FK to users
createdAt: timestamp
modifiedAt: timestamp
cherouvim
A: 

If you're on SQL Server be aware a timestamp column is somewhat misleadingly named. Whilst it can be used to track changes to a column, its value has nothing to do with the date or time. It can be thought of as an ID uniqiue within the database, nothing more. http://msdn.microsoft.com/en-us/library/aa260631.aspx

In order to know if a change has taken place you need two timstamps, like in cherouvim's answer. One is set when an object is created, the other on any modification, probably via update trigger. If they differ then the object has been edited, but you can't tell exactly when.

On SQL Server you have to use the same pattern, but with datetime columns. You can then calculate the date of the row by subtracting the creation date from the mod date.

banjollity
I don't think you need two timestamps. The cached data will have the timestamp value, and it can be compared to the current timestamp value in the database. If they match, then no further updates have been done to the database since the row was cached.
MikeW
You are quite correct. I wasn't considering the cache
banjollity
Banjollity, indeed, the cache will solve this problem on it's own. Because as long as the timestamp doesn't change, the cache won't be updated.
Sem Dendoncker