views:

1278

answers:

2

I'm planning to use MS entity framework for new web apps (come on EF v2!).

So does it make sense to plan ahead by adding timestamp columns to all entity tables in existing and future databases, to support concurrency checks? Is there any reason why it would be a bad idea to have a timestamp column in every table?

Note that the point is to add support for optimistic concurrency, not auditing.

+7  A: 

I've used timestamp columns as a matter of routine for years. Another option is a row-version, but then you need to update it etc. I've never had any problems with timestamp. One word of caution - if you ever select into a temp-table/table-var for processing, you need to use varbinary(8), not timestamp, in the temp table - otherwise your temp table will get its own unique timestamps upon update ;-p

As you acknowledge, timestamp only helps with concurrency. Despite the name, it has nothing directly to do with time, so won't help with auditing.

It is nicely supported in the MS db offerings (LINQ-to-SQL / EF / etc)

Marc Gravell
A: 

In previous projects I used timestamps a lot, and I never had a bad experience with it. Additionally I would totally exclude the Entity Framework from that decision, because that's some that might change over time.

Martin Moser