Modifying key business entity post deployment

Folks, In a layered .Net solution that we have recently deployed, we now realise we need to cater for a certain business object to be in an unconfirmed/confirmed state. A certain category of system user should now be able to create this busine开发者_StackOverflowss entity in an unconfirmed state. The entity should be invisible to the existing system and repositories etc until it is set to confirmed. The business object is used throughout the solution in lookups and other functions. The underlying SQL table that stores the entity is referenced in report stored procedures and views etc. Can anyone suggest how best to incorporate such a change? Options could include adding a binary flag to the class/table or possible storing the new unconfirmed instances in a seperate table and moving into the "live" table once confirmed.

You could store the unconfirmed entity in a sort of staging table, where it would get moved to the existing table once the entity becomes confirmed, and it wouldn't affect any current operations that rely on the existing entity table.

I would also create an entirely new/different class to represent this entity ("UnconfirmedEntity") that maps to this new table as well, then you could just build some sort of service that "confirms" this entity and removes it from the unconfirmed table to the existing confirmed table.

I would store this in a separate table, for a few reasons:

1. The unconfirmed items have different business rules, so they should be treated as a separate concept in your domain.
2. If you were to need another state, the binary flag approach would not scale, whereas the separate table approach would.
3. Retrofitting your application's lookups and other functions to check for the unconfirmed/confirmed state would be tedious and prone to error.