Subject Re: [IB-Architect] Circular Foreign Key Dependencies
Author Jim Starkey
At 11:46 AM 3/25/01 +0000, Glebas Paulevicius wrote:
>At 14:27 2001.03.24 +1100, you wrote:
>>> Circular foreign key dependencies are natural and
>>> useful (contentious statement #1),
>Can you provide a one good example to illustrate where
>to have a circular reference is natural and "a must"?

Two tables, companies and people. People has a foreign key
for company, and companies has field primary_contact which
is a foreign key for people. Utterly natural. Also living
testimony against foreign key enforcement.

It's a must for systems that depend on foreign key declarations
for semi-automatic database generation. The Netfrastructure
base application, for example, using foreign key declarations
to generate html links when displaying fields which are part
of foreign keys. A neat hack.

>I never used circular reference in my life and never felt
>a need for that. I agree, maybe due to limited experience. :)

Yup. Let your hair down and live a little. The more system
software knows about your data, the more it can do to make
your life better.

>Sounds like the must-need for multiple inheritance in C++,
>which caused a non-stop theoretical battle, and later, Java
>could live without it, though introducing interfaces.

Quite different. Multiple inheritence is mother nature way
of telling you that you screwed up your application design.
Circular dependencies seems to be a sympton of doing things

>>Among the solutions:
>> 1. alter table blah drop foreign key (seg1, seg2)
>The rules of thumb, I am using:
>1) Never use unnamed constraints;
>2) Drop constraint first, drop table last;

I'm really very fond of the "... references people" syntax --
hate to lose it over something as silly as neglect of a
committee to define socially responsible syntax. The traditional
Interbase (I) philosophy of "SQL -- don't fix it, don't improve
it, just implement it" was well and good as long as there was
an alternative for mature adults (e.g. GDML), but it doesn't
fly in this ago. Maybe the new mantra should be "SQL -- live
free or die".

Jim Starkey