Re: Is this bad database design

pcmodeler wrote:

> The organization I work for is currently implimenting an Oracle based
> product from a 3rd party vendor (it tracks training history). In
> addition to the standard tables (associate information, etc.), there
> are two tables that store a lot of unlike information (employee
> status, country, delivery type, etc.).
>
> Essentially, in order to get employee status, I have to link from the
> associate table to the lookup table to the lookup table_string table
> in order to get their status. Then, in order to get their country, I
> have to link from the associate table to the lookup1 table (a
> copy/alias) to the lookup_string1 table (a copy/alias). Then, to get
> delivery type, I have to link from the associate table to the lookup2
> table (another copy/alias) to the lookup_string table (another
> copy/alias). This can happen up to 4 or more times. It would seem to
> me that this would cause some horrible performance problem in that
> they are throwing so much unlike information into these tables.

It may be a terrible design but "unlike" information is irrelevant.

Tables are sets. There should be one table for every set. Why the status is not part of the employee record I can't imagine from your description but perhaps there is some logic behind it.

-- 
Daniel A. Morgan
University of Washington
damorgan_at_x.washington.edu
(replace 'x' with 'u' to respond)