Re: DBDesign Q

Whilst you can techincally create references this way (circular), I would recommend not doing so. With a small and simple system, this approach appears to be a good idea, however, I would suggest this is bad practice as when you work on larger systems the complexity increases dramatically. Don't get into the habit of doing this if you can.

Our old back office system at work (pre me) was built with the majority of references being circular. There were even tables which held information on which circular link was to be used (depending on the data). At the size of db we work with, this was a complete nightmare. It was one of the worst designed systems I have ever seen. Everyone on this forum would laugh if they saw the design. We have since changed this as you would expect.

Yes, you can work with them, just explain to your colleagues why you will be found mumbling to yourself later when it's become too complex. If you absolutely have to do this, FFS make sure it's documented for future developers.

Keep it simple. It will make a huge difference in the long run ! I'd recommend spending a little longer working out an easier none circular way of referencing the data.

That's my tuppence. You may well disagree.

"Joe \"Nuke Me Xemu\" Foster" <joe_at_bftsi0.UUCP> wrote in message news:<1069701707.142710_at_news-1.nethere.net>...
> "Andy" <net__space_at_hotmail.com> wrote in message <news:edb90340.0311232036.e0eeae5@posting.google.com>...
>
> > Can two entities have more than one relationship between them?
> >
> > A(A_ID PK,..., bID FK)
> >
> > B(B_ID PK,..., aID FK)
> >
> > A.bID refers to B.B_ID
> > B.aID refers to A_ID
> >
> > 2. Does it make sense?
> >
> > Product (ProductID PK, Name,., SpecialAttrID FK)
> >
> > Attribute (AttrID PK, Name,..,ProductID FK)
> >
> > Product can have many attributes. One attribute belongs to only one product.
> > There is only one main("special") attribute for each product
>
> Maybe you really want an "extender table" approach, in which
> the Product table holds attributes which all products have,
> and additional tables to hold attributes which some, but not
> all, products have, perhaps like so:
>
> Product (ProductID PK, Name, Manufacturer, Price, Mass, Volume, ...)
>
> Book (ProductID PK/FK, Author, Pages, Binding, ...)
>
> Album (ProductID PK/FK, Artist, Tracks, Media, PlayingTime, ...)
>
> Software (ProductID PK/FK, Platform, Media, ...)
Received on Tue Nov 25 2003 - 10:54:50 CET