Re: Replication

From: David Kerber <ns_dkerber_at_ids.net>
Date: Tue, 28 May 2002 12:29:08 -0400
Message-ID: <3CF3B054.BD51137B_at_ids.net>


Another way to handle this might be to add a field to your quotes table called something like Previous_Ver which contains just the pkey reference to the previous version of this particular quote number. Then you can walk the tree of previous_ver values from the most recent to the original version of the quote, no matter how many revs it goes through.

Graham Bellamy wrote:

...

> No, I was referring to the situation of revisions of things like quotes, which is really a
> revision 'history'. Say the salesman submits a quote to his client, using say Quote number
> 1001, and his client calls back and asks for some of the criteria to be modified, maybe
> for a cheaper product to be used. One option could be to go back and change the stored
> data, but then there is no way the salesman could later see the price he originally
> quoted. Another option is that the salesman must create a new quote number, say 1007, and
> write on quote 1001 a reference like "see revision quote #1007". But a nicer way of
> keeping track of which revision is which, is to keep the same quote number, 1001, and add
> a revision number, 2, to make it 1001-2, or with the salesman's initials, BJ1001-2.
> Anyway, what this means is that the majority of fields would be duplicated (getting away
> from a normalised db), which is probably an idiosyncracy of storing histories. Maybe
> another way (thinking on the fly here) is to create identical tables (maybe split up) with
> a 1-1 relationship to the original tables, to store the changes. But I think that would be
> a nightmare. Having never handled this situation of revising data before, I was wondering
> if there was some general way this is done.
>
> Hope I explained this ok.

....

-- 

Dave Kerber
Edit the return address by removing the ns_ before e-mailing

This message was entirely written using recycled electrons.

REAL programmers write self-modifying code, leading to: 
Why there is ALWAYS one more bug (courtesy of O.D. Williams):
   1.  Debuging code is  always much harder than writing it.
   2.  Therefore, if your code is as clever as you are capable of making
it, you are, by definition, inadequate to debug it.
Received on Tue May 28 2002 - 18:29:08 CEST

Original text of this message