September 3, 2016 at 3:50 pm
Some developers say that every table in a database should have a Rowversion column.
I know it's essential when Access is used as the front-end, but what about for .Net apps?
September 3, 2016 at 7:01 pm
Do you mean a primary key?
September 4, 2016 at 4:58 pm
No, a column of data type rowversion.
September 4, 2016 at 5:29 pm
rowversion is only used to determine if a row has been changed on the following cases
1 - syncronization with another systems (but it won't catch deletes)
2 - to ensure that a row has not changed since it was read by the application to the time is needs to be updated.
A alternative way for point 1 is a datetime field which gets set/updated everytime a change happens to the record or when the record is inserted - but again it won't identify deletes.
Some situations where I would not use a rowversion are
- archive tables which do not get modified
- staging tables
- tables which are only loaded from external sources and do not get updates
- aggregate tables used for reporting (as these tend to be regenerated fully from source)
so bottom line is that the need for it depends on the application and on the usage of the table.
September 12, 2016 at 5:01 pm
It sounds like a good idea in a high transaction system. But maybe the business should be the one deciding that as opposed to the developers. If I am a hotel chain and I show a customer rooms available that I pulled, while a update query was running in the background already, the room may not be available when I try to book it. Whereas a lock would have prevented that row from being pulled.
----------------------------------------------------
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply