Re: Database design qn for one-to-many relationship

On Wed, 5 Mar 2003 15:28:26 +0100
"Jon Maz" <jonmaz_at_surfeu.de.no.spam> wrote:

>
> One thing in particular disturbs me in the first approach, and that is
> the design of tblParentTypes, where I feel uncomfortable with the
> ParentTableName field being a VarChar that contains the name of the other
> tables to be referenced. I feel that this kind of connection between
> tables should be taken care of by db relationships, and not by having the
> name of a table as a field in another table.
>
> The first approach does however have the advantage of requiring
> considerably fewer tables, and I think it makes writing the OOP layers
> easier too.
>
> Thanks for any help,

If you want your relation database to look and feel as object oriented as possible, be consistent and store attributes by them self and keep the links of any relation (association/superrelation) in one table per relation.

This is however not very speedy and will require multiple queries or joins to find the other end of any relation.

So your choises are speed or a good looking RDB. If you still can't make up your mind you might want to consider using an OODB.

karl Received on Wed Mar 05 2003 - 17:03:56 CET