> 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.
>

Cause you should store what you know, you store "information".

Making up data is a strange way of keeping "information".

If there's no record to be referenced, use NULL, that's what it means:
nothing, no information. A value can have two states: informational
(filled, NOT NULL) or no information (NULL).

With regards,

Martijn Tonies
Upscene Productions
http://www.upscene.com

Download Database Workbench for Oracle, MS SQL Server, Sybase SQL
Anywhere, MySQL, InterBase, NexusDB and Firebird!

Database questions? Check the forum:
http://www.databasedevelopmentforum.com