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 administrator, 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 allowed. 2) If there is no documentation, the application developer should get the DBD to produce some. 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 presumption.
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?
Then I'm embarassed that I didn't recognize or remember it. I should have done so.notation, by the way -- I hadn't seen it before.) I don't see the
I believe the notation comes from E.F. Codd.
Having a patient table, and gender-specific child tables becomes
a much more attractive option in this scenario.
Agreed.
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.
Bruce Feist
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
