Re: Replication

From: David Kerber <>
Date: Wed, 29 May 2002 13:25:44 -0400
Message-ID: <>

If you really wanted to get tricky with it, you could save that other info which wouldn't change from version to version of the quote in another table, but that may be more work than it's worth in space saved. At this point, it's really a decision you have to make with the trade-offs between application complexity, space usage and flexibility.

Graham Bellamy wrote:
> The Quote table itself wouldn't hold much info (Date, salesman, client, job site
> info...,around 15 fields), but I don't see how I could get away from duplicating
> everything that would cascade from a particular quote number, as I don't know which of the
> child records he would want to add/delete/edit. In your example there would be many items,
> which would have to be duplicated, but in certain situations (mine included) each item
> could have many child records etc. In theory, that's a lot of duplication. Though in my
> situation, there's not a great amount of actual data being stored.
> Graham
> "David Kerber" <> wrote in message
> > How much data are you storing in the quote record itself? If it's just
> > pointers to customer ID's, with the customer details stored in a
> > different table, there's not much data being duplicated. Maintaining
> > the pointers to the child records is a bit more work, but if you break
> > up your quote info a bit more, you can handle it:
> >
> > tblQuotes
> > QuoteID AutoInc
> > QuoteNum String (Your 1001-1, 1001-2, etc)
> > SalesPerson Long
> > ...
> > Other info as needed
> >
> >
> > tblQuoteDetails
> > QuoteID Long
> > ItemID Long
> > Qty Integer
> > QuotedPrice Currency
> > ...
> > Other info.
> >
> > (with one record for each item on each quote)



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 Wed May 29 2002 - 19:25:44 CEST

Original text of this message