> Why do I think boolean columns are a little different? You could
> interpret that null is 'similar' to false because it is not true,
But I'm not. I think SQL has it right: null is neither false nor true.
Out of context. I never said it was and 'you' meant 'anybody'. Sorry
if it was misleading. Don't take things so personally.
But that's not even true if we ignore the true 3-valued yes/no/maybe
case. The intent of SQL null is to represent *unknown* data. Imagine
storing data about your friends, including whether they own a car. You
might have a 'has_car' column, which would of course be boolean.
Now, you may not know (because you haven't asked) whether some of your
friends own a car or not.
That is the first thing I ask my friends. Don't you?
So what to put in has_car? You can't put
true. You can't put false. Guess what, you put null!
I'd put "I didn't ask" but that wouldn't fit in the boolean
Very true, though.
> That is
> different IMO than, for example, a date column, which could very
> possibly be conceived to contain either a date or no date at all.
> Could a boolean column be conceived to be null?
Yes, absolutely. See above.
You have certain ability to repeat yourself.
> Certainly, but again,
> not the most likely case in my experience.
But common enough. Don't pretend it doesn't happen.
> Although an interesting proposition I don't think I would ever use a
> boolean column to store "true/false/maybe sort of things".
Fragmented. Because of the explanation I gave. Did you read the whole
paragraph? (see below).
> Of course,
> the column could be created to allow it but that, IMO, would defeat
> the purpose of the boolean column.
No. SQL booleans are three-valued. It makes sense to use that
I agree with you in the case of *unkown* data.
(From above: you see? this next paragraph explains why. I knew I had
written it somewhere!)
> I would rather use a different type
> because, as it happened to me in the past, a 'true/false/maybe' sort
> of scenario can quickly become a 'true/false/maybe/likely/not that
> likely/very likely' sort of scenario and then I would need to change
> my DB and code.
Then change it *at that time*.
Sure, and spend who knows how much time changing DB and code if that
You can't know what will happen in the
future, and therefore you can't really design for it. Remember YAGNI.
Don't overdesign. Don't anticipate if anticipation does not give you a
YAGNI is a very good principle to follow and I certainly try to adhere
to it as much as possible, however it's not the only thing to take
into consideration. There is something else I try to use as much as
possible, it's called personal experience. There have been times when
because of adhering to YAGNI I had to go back and rework A LOT of
code. Now I prefer 'overdesigning' a little bit if I see that there is
a possibility that not doing so might come back to bite me, even if
the only "present benefit" I get is to have peace of mind and know
that I won't get bitten by it. I'd rather spend 30 or 60 extra minutes
giving a universal solution to a problem or generating related
additional functionality that I might see a use for (but not needed
right now) than having to go back and spend days reworking something
because of those 'saved' 30 or 60 minutes.