>
> On Feb 24, 2011, at 1:55 PM, David Mintz wrote:
>
> Thanks for the helpful observations. The trouble with NULL is that it's
>> too vague. I have cases where I need something that means "not applicable,"
>> "unknown," or most often, "we don't care" because the proceeding took place
>> before the generic duty magistrate whose actual identity really isn't
>> important, and users don't want to be forced to identify her/him by name.
>>
>
> Fair enough. For what it's worth, it has been a subject of debate over
> many years among relational theorists whether NULL should be a single value
> or should there be multiple "types" of NULL for different purposes. E.g.
> "applicable but unknown at this time" is different from "inapplicable".
> There have been proposals for up to four different types of NULL-like
> value.
>
> On the other extreme, people like C. J. Date argue strongly that any kind
> of NULL is inappropriate in the relational model.
>
> In your case, I'd still recommend using NULL for the foreign key, simply
> because it solves your issue with -1. The worst solution in my view is to
> use a non-null value to do what NULL is meant to do. Once you start saying,
> "we can't use DRI constraints because..." then IMHO it doesn't matter how
> you finish that sentence, because you've already broken your logical
> database design.
>
> If you still need to distinguish between "n/a", "unknown" or "we don't
> care" then add another column called `why_no_judge` or something.
>
>
Say no more! I'm convinced. I am sort of an enthusiast programmer, a guy
with a non-IT job title who has picked up skills to solve problems in the
workplace (there being no one else in the organization to do it). In my
non-expert opinion this is a situation where you have to do something a
little ugly, that doesn't feel completely right, no matter what. And I think
your solution is less ugly and will work better than what I was going to do.
Thanks.
--
David Mintz
http://davidmintz.org/
It ain't over:
http://www.healthcare-now.org/
没有评论:
发表评论