Re: Table design decision

Hello,

I am a little bit late for the tread, but I have an idea about it and want to hear your comments.

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.

What about a master parent for all 50 object tables? It is less a master parent than an ancestor.

create table ObjectAncestor
(

   ObjectId Integer;
);

create table ObjectType1
(

   FK_ObjectId Integer reference ObjectAncestor on delete cascade; )

create table ObjectTypeN
(

   FK_ObjectId Integer reference ObjectAncestor on delete cascade; );

create table ObjectProperties
(

   FK_ObjectId Integer reference ObjectAncestor on delete cascade; )

So instead of delete ObjectTyp1 you delete ObjectAncestor and the rest happens by it self.

What have I overlooked?

Ciao Heinz Z. Received on Mon Jan 23 2006 - 06:28:33 CST