I am not sure this will work, since there are about 30 tables in the schema and each table has various relationships with one another. During the review process, the reviewer can quit anytime and maybe come back later to resume on it. Having said that, there are several starting points in the review process, meaning the reviewer could start out looking and making changes to the financial information page, which 3 or 4 pages down from the submiter's contact info page. By 'inserting new records' to the financial table right off the bat, I would get a database referential integrity error, because the financial table primary key ultimately traverses back up to the contact table. So I guess I don't see how by 'inserting new records' would work?
Maybe you can help clarify further and I apologize if I didn't understand your suggestion.
Nick Han
>>> [EMAIL PROTECTED] 04/21/04 01:28AM >>>
Nick Han said:
>
> I am more interested in database design help. What I am thinking
> right now is right after the deadline, before the reviewer making
> changes, I dup the db schema and back that up, and the current
> schema will have the current data, including changes made by the
> reviewer. If there is dispute and I need to compare original
> version and edited version, I can toggle my variable that has the
> schema name?
I think there is a better way: never update records :-) Instead of
updating, insert a new record and timestamp it. If you just show the
latest version as the working version in the frontend nobody knows the
difference, but you can track all revisions in the background if you
want to.
(This is the same solution as Barney proposed, but with a slightly
different angle on the explanation.)
Jochem
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
