There is an application that involves billing enterprise customers for the services their customers utilize. The database schema does not properly reflect the business model. For instance, on a given account, services may become activated and deactivated. There is only a column to represent when the service was deactivated and the code in place just updates that same row if the service is reactivated rather than adding a new row. Ideally, a row would be added when a service activates and updated when deactivated, and there would be a column to represent the activation date.As it stands, there is no solid billing history for these enterprise customers, but there needs to be from here on out. Do we set a cutoff for the legacy model that was corrupted and wipe the table clean? Do we add the appropriate column and start working with the table properly and just check for rows that have a 'activated date' of null to detect legacy? There must be several ways of handling this, but I have no experience with this kind of situation and would like to hear out some various approaches.
How to salvage a business model from a mismatched database?
database design;domain model
Of course the way things are now, there is no solid billing history due to the mistakes that were made.As far as I understand your question, your database scheme is missing some features (like history information), and you have problems to change it because you don't know the full impact into your existing system. One approach for dealing with that kind of situation is to solve the problem with upward-compatible extensions to your data model. For example, you need a history in your billing table? Add a new billing_history table, with exactly the same columns as your billing table, and an additional record version number as well as a validity date column. Then add an after update trigger to that table which makes a copy of the current billing record into the billing_history table whenever the deactivated flag is reset to activated. Now, you can add new modules to search, display and access that history table, and you don't have to change anything in your existing modules.The details may be different in your situation, but I hope you get the idea.