Your skill will accomplish what the force of many cannot |
|
PerlMonks |
Re^8: DBI: passing undef as an argumentby ruzam (Curate) |
on Aug 11, 2009 at 02:57 UTC ( [id://787468]=note: print w/replies, xml ) | Need Help?? |
In which case the database would have a field "number_of_children", next to "age_of_oldest_child".
And what if the number_of_children is unknown? Do you create yet another field for this? Do you keep qualifying your missing data definition until you run out of physical fields to add to the table? The fact that you have defined the field as containing nulls to begin with implies that the field is no longer just a value, but a value and a state pair. You can't check the value without ALSO checking the state, regardless of what NULL may be used to signify. Null might just as well indicate that a joined table has no matching row, which has nothing to do with the values or the reason they're stored. If you're going to argue that null has no place in the relational model, then you're going to have to support an argument that JOIN has no place in the relational model first. How can you ever be certain that the results you ask from the database are correct?By asking for results that can be certain. "Select all people in the database who's age is not 10 or who's age IS NULL" just as you would "Select all people in the database who's age is not 10 or who's number_of_children is 0". I don't see any inconsistency here. If you chose to use nulls, then you MUST test for nulls or accept the consequences. Your argument appears to claim that testing values fails when nulls are involved but from my point of view, your argument fails to accept that the null state needs to be part of the test. It's not the "Aristotelian" logic that's been subverted, but the test which is incomplete. I think the real point of your argument may be that working with null values is prone to error and should not be used without careful consideration of the traps that can result. If this is so, then I heartily agree. It's far easier to simply avoid nulls then it is to try to stay on top of situations where they may misbehave. And if you do any DB2 interaction through COBOL you'll appreciate not having to code in (and check) the extra 'null indicator' flags ;)
In Section
Seekers of Perl Wisdom
|
|