database design

Results 1 to 3 of 3

Thread: database design

  1. #1
    Join Date
    Dec 1969

    Default database design

    Hi there,<BR><BR>All the examples that I have seen for the design of an e-commerce database have an orders table which links the customers&#039; details into a customer table and the products, which comprise the order, into the catalogue table.<BR><BR>What concerns me is if a customer changes, say, their shipping address some time after order x has been sent. Because the orders table links to the customer details table order x will now say that the goods were shipped to a different address than they actually were. What good is a record of an order if the data which describes it can be modified? (Of course, this could happen with products too - though I suppose this would be less likely as long as one is maintaining all the products that have ever been in the catalogue.)<BR><BR>I&#039;ve decided to beat this problem by making a new and separate copy of all the customer and product information in the orders table for each order. <BR><BR>Is this a bad design?<BR><BR>Thanks.<BR><BR>I.<BR><BR>

  2. #2
    Join Date
    Dec 1969

    Default RE: database design

    What I would do is to have a separate table of all completed orders, which would hold the correct information - like a history table, in effect...<BR><BR>It&#039;s not really bad design..<BR><BR>j

  3. #3
    Join Date
    Dec 1969

    Default Good question..

    *One* way (and there are several) is to have "versions" of some kinds of records (such as customer address, of course). And you link a particular invoice to a particular version. Yet the versions are themselves linked, so you can always find the most current one. This is all a *lot* easier with an ODBMS that supports versioned objects natively (huge grin).<BR><BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts