Re: Table design decision

Tarby777 wrote:
> Well, I don't think the 50 existing tables are badly designed; there
> are 50 different kinds of objects that can be created in the app, and
> each one is sufficiently different from the others to merit having its
> own table so I don't think that that part of the schema needs to
> change. The bad design I was alluding to is that the user-defined
> properties for all these different kinds of objects are all stored in
> one table, which has 50 FKs. I imagine that when the app started out,
> there would have been substantially less than 50 object types, and it's
> probably just evolved into the current monster over time.
>
> Anyway, after much typing, I now have the DDL for my 50-new-tables
> option. If anything earth-shattering comes out of my testing, I'll
> report back. Thanks again to all who posted.
>
> Regards,
> Tarby

I respectfully disagree. At least based on what you have written here so far. Consider the following lookup table design:

ID NUMBER(10),
OBJECT_TYPE VARCHAR2(5),
OBJECT_VALUE VARCHAR2(30)); It can handle an infinite number of objects of an infinite number of types ... all in one object. I'm not saying it would work for you ... but 50 lookup tables ought to drive any report writer that has to deal with this later absolutely crazy.

Ah you have already met with the report writers and gotten their requirements and input haven't you?

-- 
Daniel A. Morgan
http://www.psoug.org
damorgan_at_x.washington.edu
(replace x with u to respond)