> Jochem,
> 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]
