At 05:40 AM 30/09/2004 -0300, you wrote:

>Svein Erling Tysvær wrote:
>
> >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.

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

./heLen