Re: ER diagram question

Hi Peter,
Thanks very much, this was exactly the type of comment I was hoping for. I could not remember if there was some fundamental "wrong" in having circularity in a database design or whether it was preferable to not have circularity, but no big problem otherwise. I tried running all the queries that I know at this point I will need, and the circular design did not present any apparent problems, so therefore I didn't think it would be a problem but wanted to make sure nonetheless. Therefore, thanks very much for setting my mind at ease! :-)

All the best, Jonck

"Peter Mount" <info_at_petermount.au.com> wrote in message news:<40123ea0_1_at_news.iprimus.com.au>...
> Hello
>
> I had the same comment about circular database designs at my old school. The
> basic problem is the fact that it takes up extra hard drive space through
> having redundant keys, leading to a bigger file size.
>
> Yet, at the very same school this was contradicted in a different module.
>
> I have, as a circular design:
>
> One to Many between Customer and Projects ie Customer.CustID being primary
> key with Projects.CustID being foreign key
>
> One to Many between Projects and Communications ie Projects.ProjectID being
> primary key with Communications.ProjectID being the foreign key
>
> One to Many between Customer and Communications ie Customer.CustID being
> primary key with Communications.CustID being the foreign key
>
> You may want a primary key just for each communication, ie without a
> corresponding foreign key in another table.
>
> I don't know enough about your business rules but I would've thought that a
> communication can have more than one topic (that's how I'd model it). If
> this were the case you would have a join table between Projects and
> Communications
>
> Hope this helps
>
> Peter Mount
Received on Sun Jan 25 2004 - 14:41:07 CET