Jon Frisby wrote:
>>Even if I grant you that, the DB designer should have produced the
>>documentation. I'm willing to place the blame on both people; either
>>one could have avoided the problem. But, the DBD (data
>>if you prefer) is more likely to have been *aware* of the
>>problem in the
>>first place; it's their job to understand the data and serve as a
>>reference to it. Even if the programmer caught the
> So in this example we have a situation where neither party practiced
> sufficient due-diligence, resulting in a potentially costly mistake for
> the company when proper care on the part of either party would have
> prevented the situation entirely. That sort of procedural error is a
> risk no matter how cautious you are about the design.
I'm not at all convinced that we're disagreeing at this point. To enumerate what I think
we agree on:
1) It is the responsibility of the DBD to document the meaning of NULL if NULLs are
2) If there is no documentation, the application developer should get the DBD to produce
3) If the DBD is unavailable and the meaning of NULL in a column is undocumented, the
application developer should look at existing data to see how NULLs are being used.
(This assumes that they can tell from looking at the data, and that there is existing
data to look at.)
>>When you think you understand the system, the tendency is to
>>go no deeper.
> True. But that's a habit that should be beaten out of every
> engineer/admin. It's the worst kind of laziness and arrogant
In theory I agree, I suppose, but clearly in practice belief that you understand the
system is the only way to know (I use the term loosely) that you can proceed and use it!
>>Why? If it's documented, it's a reasonably intuitive, clear, and
>>probably efficient way.
> Marks (nulls) are a separate domain from strings. The empty string is
> just another value out of the set of possible strings but you're
> arbitrarily redefining it into the domain of marks. Yes, that's a
> nitpicky detail.
Nitpicky details are important, and you're right. There is a difference, although it's
subtle, between not having a middle name and having a middle name of ''.
> However, consider the potential scenario of having a *fixed length*
> column for middle name -- CHAR(20) instead of VARCHAR(20). MySQL
> doesn't pad CHAR columns with spaces,
I didn't know that. What *does* it do if you specify a string literal that's smaller than
the CHAR(20) field, then? Pad it with binary zeros?
>>notation, by the way -- I hadn't seen it before.) I don't see the
> I believe the notation comes from E.F. Codd.
Then I'm embarassed that I didn't recognize or remember it. I should have done so.
Having a patient table, and gender-specific child tables becomes
> a much more attractive option in this scenario.
> And here we come to the big controversy. E.F. Codd liked the idea of
> having two possible NULLs (A-mark and I-mark). C.J. Date started a
> ruckus over the issue of whether or not NULL is a good idea back in 1988
> or so. The debate has raged since.
I'm aware of it. I personally take what I consider to be a pragmatic approach -- NULLs
are a tool which can be used or abused, and which have both merits and pitfalls. I
consider the ambiguity of meaning a pitfall, which can be adressed through documentation
and sometimes constraints.
> One solution I've seen proposed is to allow the programmer to define
> NULL as an enumeration. Basically "this value can contain a *value*, or
> it can contain one of N specific NULL values that I define".
I assume that this would be done by the database designer rather than the programmer! It
sounds reasonable enough, but possibly overengineering.