At 11:50 AM 7/01/2007, you wrote:

>I've been tasked with merging our internal DVD, classical music and
>general music databases (currently stored in 3 separate MSSQL
>databases) into one DB.
>
>In the new design title information for all 3 types is stored in the
>PRODUCT table and release information per title is stored in the
>PRODUCT_DETAIL table. Classical products have more information at the
>title level, so that is stored in the CLASSICAL_PRODUCT table (which
>is 1:1 with PRODUCT).
>
>I need a way of being able to select from the PRODUCT table based on
>type, and rather than adding a "type" column to PRODUCT (e.g. 1 = DVD,
>2 = general music, 3 = classical) I thought considering I already have
>a CLASSICAL_PRODUCT table why don't I just add a DVD_PRODUCT and
>MUSIC_PRODUCT table that only list their product ID's so I can select
>based on type but using a join instead.
>
>Is there any advantage doing it one way over the other?

It's not clear quite what the question is here but I'll take a wild
guess that you mean, is it better (or worse) to save a byte or two in
the master table record by creating and maintaining two entire extra
tables containing no data except the key.

Or did I misunderstand the question?

Could you perhaps describe a bit more clearly why you think you would
need to add these no-user-data tables?

Depending on what you're aiming for you can:

- perform an inner join between PRODUCT and CLASSICAL_PRODUCT with or
without a limiting WHERE clause and return data for only those
Products that have a CLASSICAL_PRODUCT record. You won't get general
music or DVD records but you also won't get classic products that
have no CLASSICAL_PRODUCT record

- perform a left outer join between PRODUCT and
CLASSICAL_PRODUCT. That way you get all the products, plus extra
data for the classic products

- plus other variants of left, right joining with or without nulls in
the right stream...

./heLen