Re: Foreign key problem

From: mAsterdam <>
Date: Tue, 13 Jun 2006 22:11:12 +0200
Message-ID: <448f1bbc$0$31649$>

Kenneth Downs wrote:
> mAsterdam wrote:

>>Kenneth Downs wrote:
>>>frebe wrote:
>>>>I am working on an application which need a data model that reflects
>>>>the schema structure. My tables are ("*" indicates primary key column):
>>>>columninfo(*table_name, *col_name)
>>>>fk(*fk_name, pk_table, fk_table)
>>>>fk_column(*fk_name, *fk_column, pk_column)
>>>I can tell you how we did it, and perhaps this will help.
>>>Our tables look more like this:
>>>TABLEINFO (*table_name)
>>>COLUMNINFO (*table_name, *col_name)
>>>FK (*table_name,*table_name_par)
>>This rules out more than one FK in one table referencing one other.

>>Use /roles/ to name your FK's.

> In the limited example given in the post, yes.
> In fact we have half-dozen or so other flags on the FK table, two of which
> combine to provide multiple FK's between any two tables. We employ a
> "suffix" and a "prefix" property, each of which is used to alter the names
> of the columns in the child tables by adding the obvious prefix or suffix
> to each column in the child table. Hence a declaration like so:
> table employees {
> column employee { primary_key: Y; }
> foreign_key employees { suffix: _sup; }
> }
> or:
> table fk {
> foreign_key tables { suffix: _child; }
> foreign_key tables { suffix: _parent; }
> }
> We have no desire to completely rename columns, as this leads to
> obfuscation. This approach to naming columns is not for everyone, but we
> like it.

By using _child, and _parent suffixes
(which, BTW, by themselves do /not/
facilitate more than one FK in one table referencing one other) you are mixing
the language in the universe of modeling (the language used to describe your model) with the language of the universe it models.

By using roles for naming foreign keys you stay within the language of the modeled universe and it naturally facilitates more than one FK in one table referencing /one/ other. Received on Tue Jun 13 2006 - 22:11:12 CEST

Original text of this message