apologies. I had assumed that the contact was a known entity to the system
that wouldn't change. They'd have an account that would allow them to
access the application process.
If the contact is part of the application data, then you'd handle it just
like the financials. It would just be another table that is bound through
the central application table.
Cheers,
barneyb
> -----Original Message-----
> From: Nick Han [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 21, 2004 11:22 AM
> To: CF-Talk
> Subject: RE: advice needed on multi-version data model design
>
> Barney, thanks for your advice. I understand your suggested
> solution for the simple example I wrote here. But my main
> concern in practice is that any field in any table could
> change. So for an application where all information
> submitted by the original submiter is complete, the reviewer
> could now start the review process by editing the contact
> info first. Because of reviewer has not reviewed any
> application-level data yet, how would I tie the new inserted
> contact record back to the application table if I start out
> by inserting a new contact record? I am still a little puzzled.
>
> Nick Han
>
> >>> [EMAIL PROTECTED] 04/21/04 10:12AM >>>
> Your financial table shouldn't have a reference to a contact.
> It should
> have a reference to an application. That application should
> then have a
> reference to a contact. Then you can add an arbitrary number
> of records in
> the financial table without ever needing worry about the contactID's
> referential integrity.
>
> The application table is the abstraction layer between your
> multi-versioning
> system and the rest of your schema. Outside your application
> table, the
> rest of your DB needn't care if you have a single version of
> each app, or
> multiple versions of each individual page in the app.
>
> Cheers,
> barneyb
>
> > -----Original Message-----
> > From: Nick Han [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, April 21, 2004 9:58 AM
> > To: CF-Talk
> > Subject: Re: advice needed on multi-version data model design
> >
> > 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]
