Why can't you have a foreign key and allow that field to be null? Of course, the primary (or unique) key being referred to by the foreign key cannot be NULL, but the field defined as a foreign key would normally allow NULL. So why would you need any triggers for data integrity?

As for copying the description - sometimes relational theory isn't identical to the most practical solution. Copying the description to the invoice table to avoid invoices from changing if an article changes its name sounds like a practical solution (available place on hard disks aren't as important as it once was).

I'm also curious why Martijn answered your original question with a plain 'no'. I'm not saying that 'yes' is a better answer, I'm just curious about his reasons.

HTH,
Set

-----Original Message-----
From: firebird-support@yahoogroups.com [mailto:firebird-support@yahoogroups.com] On Behalf Of Sergio H. Gonzalez
Sent: 14. oktober 2009 16:31
To: firebird-support@yahoogroups.com
Subject: Re: [firebird-support] very basic questions about FK

Thanks guys for the quick answer!! I use the FK just to check data integruty.
This is an example:

When I do an invoice, most of the items of the invoices are a reference to the
article's table (*) but some times the user can add a "free item" to the
invoice. It means: a line in the invoice that is entered by the user wich don't
point to an article. In that cases I set teh ID_article field to -999 and in the
article's table I have a record: ID_Article = -999 / Description = 'Free Item'.
That way I can use a FK to presererve data integrity. If I allow nulls in
ID_Article I could check for data integrity whith triggers... so... what should
I do?

-s

(*)I know that this is NOT very good, but I also copy the description of the
article in the invoice detail table... the problem is that the description of an
item may change and I don't want the invoice to change any of the descriptions)