| Subject | Re: [IB-Architect] Circular Foreign Key Dependencies |
|---|---|
| Author | Jim Starkey |
| Post date | 2001-03-25T17:20:13Z |
At 11:46 AM 3/25/01 +0000, Glebas Paulevicius wrote:
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.
software knows about your data, the more it can do to make
your life better.
of telling you that you screwed up your application design.
Circular dependencies seems to be a sympton of doing things
right.
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
>At 14:27 2001.03.24 +1100, you wrote:Two tables, companies and people. People has a foreign key
>>> 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"?
>
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 feltYup. Let your hair down and live a little. The more system
>a need for that. I agree, maybe due to limited experience. :)
>
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++,Quite different. Multiple inheritence is mother nature way
>which caused a non-stop theoretical battle, and later, Java
>could live without it, though introducing interfaces.
>
of telling you that you screwed up your application design.
Circular dependencies seems to be a sympton of doing things
right.
>>Among the solutions:I'm really very fond of the "... references people" syntax --
>>
>> 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;
>
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