in reply to Concurrency control in web applications
So, we've reduced collisions to those fields that are being changed together. The way I've seen this solved is to keep a history of all changes to all business-related fields. I'm not talking about an UPDATED_ON field for the table. I'm talking about a real history table, along the lines of:
ID TABLE_CHANGED COLUMN_CHANGED ACTION OLD_VALUE NEW_VALUE WHEN BY_WHOM
Then, you have a history page, where you can see what changed, when, and by whom. This history table solves this problem, and a host of other problems, plus provides capabilities like rollbacks and the like. Now, I wouldn't suggest this solution for all situations, but it definitely seems warranted for things like user information. Remember, not everything should have a technology solution, especially when it's a human problem.
------
We are the carpenters and bricklayers of the Information Age.
The idea is a little like C++ templates, except not quite so brain-meltingly complicated. -- TheDamian, Exegesis 6
... strings and arrays will suffice. As they are easily available as native data types in any sane language, ... - blokhead, speaking on evolutionary algorithms
Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.
|
---|