in reply to Database design and Class::DBI

I don’t think the database is well designed, but I know the database design is not from you. ;-)

I can understand why there are three tables, and I actually agree that’s a must, if you want to make the price-product info fully normalized.

But the data in price-type table should be only used for two purposes:
  1. As a data integration reference, we can use it to check and make sure all price-id’s in all other tables are valid, i.e. there is row in this table for that price-id.
  2. Store the visual presentation for each price-id, for example, if you want to print some report, instead of showing the less meaningful price-id, you may want to show the price type.
But to use price-type as part of unique keys elsewhere is a bad idea. Only price-id should be used for that purpose.

In the product-price table, instead of storing price-type, should storing price-id, and form unique index together with product-id.

Replies are listed 'Best First'.
Re: Re: Database design and Class::DBI
by iburrell (Chaplain) on Mar 05, 2003 at 22:01 UTC
    I am Ovid's coworker and this part of the database was designed by me.

    The product_prices table does store the price_id and uses (product_id, price_id) as the primary key. It wouldn't be normalized otherwise. The name in price_types is only used for display purposes.

      Hey, slacker! Get back to work! Sheesh. How are we going to get anything done if you're playing on Perlmonks all day? ;)

      Cheers,
      Ovid

      New address of my CGI Course.
      Silence is Evil (feel free to copy and distribute widely - note copyright text)

      Okay, then I don’t have a single problem with the database design. (Scary, the guy did the database design is also here, good I didn’t say any thing too strong ;-).

      To be serious, I don’t have problem with your database design, I said those all because of Ovid’s typos …Well, he is a good guy made couple small typos ;-)

      Good to talk to you. Perl rules.