> > >German, you say "not unique" for the FKs. Exactly how "not unique" is
> > >this? It is OK to have a foreign key to customer in the order table,
> > >but it is not OK to have a foreign key to status when 90% of the
> > >records have the status 'Completed'.
> > >
> >I font have that kind of foreign key (like status) but yes can happen
> >there the same key in the 90% of records.
> >Thats is bad? So please explain me how can i manage that in a real life
> >app. If that key is by example payment, how can i know if the people
> >will pay with cash or visa before create the table?
>
> Perhaps you could help us by explaining why you need foreign keys on such
> columns.
>
> >I really dont understand why that is a trouble in firebird.Must be
> >another solution. I dont want to remove foreign keys and lost
> >referential integrity.
>
> Maybe you and we have different notions of "referential integrity". For
> example, one would not create a table to implement declarative referential
> integrity on a two or three state condition that won't change: one would
> create a domain with a CHECK constraint.

Helen, I disagree. Perhaps for this particular problem, one might create
a CHECK constraint, but -- in general:

* if the number of options can change -> FK
* if there's more than just 'CASH' in the table, but a whole record with
other data -> FK

> create domain d_paytype char(6)
> CHECK (VALUE IS NULL OR VALUE IN('CASH', 'CHEQUE','CREDIT'));

IMO, this really is a FB implementation problem.

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com