quote:
I think I understand where you are going...The only way anything can be written to the production TimeTable is via the stored procedure UpdateTimeTable. No applications or users have write permissions to this table. There is only execute permissions on the stored procedure. This stored procedure gets called from a SQL job that is scheduled to run daily. The stored procedure is never reference anywhere in the web application.
So, the short of it, is that no one except the DBA or myself has rights to the sql server to run this stored procedure. There is really no way for any 'bad' data to get into the table unless the dba or myself were to intentionally put it in there.
But why define a table that even has the possibility of bad data in the first place?
Would you define two tables that have a FK-to-PK relationship, but not explicitely declare the relationship, hoping that all applications programmed against them correctly enforce the data integrity externally?
These are the kinds of problems that the Relational Model was invented to solve.
Do you have other exceptions like this in your system? Are they all documented? What happens when you or the DBA leave the company?
Here's an article by Joe Celko that goes into more detail:
http://www.intelligententerprise.com/030531/609celko1_1.shtml?/database
If that link won't work, try googling for "Celko" and "Logic of Failure".
TroyK