Minty
AWF VIP
- Local time
- Today, 03:12
- Joined
- Jul 26, 2013
- Messages
- 10,371
I may be answering my own question here but here goes; Over time I've inherited a number of systems that have a "current status" field.
This is handled in two ways depending on the system in use;
Method 1 - A single status field whose value is changed by other processes.
Method 2 - A child record with a status and date of change.
Method 3 - In a new system I recently put together I thought about and have implemented a calculated status based on criteria. This is done through a (pretty complicated) function on SQL server and incorporated into the views used by the system.
I can see obvious pitfalls in the first method as it requires other things to happen in the correct order, however it enforces a process structure.
Method 2 is straightforward, but open to some abuse as any process status can be set at any time. (There is no restriction on what status is set based on current status, maybe there should be?) Simple to maintain though, it's simply a table with a Status ID, StatusText and a Fuller description.
The 3rd method seems the most robust but also the most difficult to maintain, particularly if the business logic starts to get really complex. Additional status's have to be programmed into the existing logic.
My question is really about how other developers handle this? Or do you take it situation on it's merits? Is there another technique I've completely overlooked.
This is handled in two ways depending on the system in use;
Method 1 - A single status field whose value is changed by other processes.
Method 2 - A child record with a status and date of change.
Method 3 - In a new system I recently put together I thought about and have implemented a calculated status based on criteria. This is done through a (pretty complicated) function on SQL server and incorporated into the views used by the system.
I can see obvious pitfalls in the first method as it requires other things to happen in the correct order, however it enforces a process structure.
Method 2 is straightforward, but open to some abuse as any process status can be set at any time. (There is no restriction on what status is set based on current status, maybe there should be?) Simple to maintain though, it's simply a table with a Status ID, StatusText and a Fuller description.
The 3rd method seems the most robust but also the most difficult to maintain, particularly if the business logic starts to get really complex. Additional status's have to be programmed into the existing logic.
My question is really about how other developers handle this? Or do you take it situation on it's merits? Is there another technique I've completely overlooked.