Alexander Gräf wrote:

>
> A FK is a declarative way of defining relationships between tables.
> For example, I'm using an ORM-tool which automatically maps relations
> between tables to 1:n and n:m class collections.

I agree. One thing that the SQL committees have done right is maintain
the separation between logical and physical attributes of the database.
Indexes - like table spaces - are physical structures. Foreign keys
are part of the logic of the design. One should not derive from the other.


The InterBase implementation of foreign keys automatically generates
indexes for foreign key relationships. That's a problem - and a hard
problem to correct. The code that compiles and optimizes queries
"knows" that where there is a foreign key, there is an index, and lots
of complex code depends on the existence of those indexes. It can - and
probably should - be changed so the indexes can be optional, but the
change won't be simple, and is very unlikely to show up in Firebird2.


Regards,


Ann