Sergio H. Gonzalez ha scritto:

>> Why you don't want to let field to be null AND _use_ foreign key?
>
> Well... at this point, I'm sure I was WRONG!! But somehow I believed that that
> wasn't a "good practice"... I have just one domain "ID" in my databases defined
> as not null and I used it to ALL my IDs (PK or FK)...
>
> I'm happy I asked here, because I now realize there's nothing bad in having FK
> null !! So I will create a new domain "ID_FK" which allows null and will change
> all (ohh, my god!! there's a lot!!) the FK fields to that domain and will use
> null values when I have nothing to point...
>
> THANK YOU VERY MUCH TO ALL OF YOU !!
>
> -s
>
> PS: I'm also happy to know that is not that ugly copying the article's
> descriptions to the invoice detail !! :))
> Sometimes I couldn't sleep thinking if I should implement something similar to
> Mark's suggestion... and again I'm happy to learn that most of the people think
> is not a good idea to add such a complexity in de data model...
>
>

I have a program that creates invoices and I choose not to use
referential integrity between invoice details and articles. When the
user adds an article I copy all the relevant info from the article to
the invoice detail, then the user is able to change anything. The
invoice must not change if the user changes the article so I think that
it is better to separate data. If the user wants to add a free item he
simply leaves the article id blank and he writes whatever he wants in
the other columns.
In my implementation the user can even delete an article if he wants,
even if it is present in some invoices, and the invoices will still
print the same.
Of course this could be a problem for some implementations, but it was
not for mine.

Fulvio Senore