| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Useful Oracle books - C.J. Date theory vs. practicality
Hi Dan,
sorry, I could not resist -- see inline ...
Kind regards,
Lex.
It is important to understand that null might mean "We don't know this property of this entity." OR it might mean "This property does not *apply* to the entity."
LDH> I dare to disagree here: nulls are only allowed to represent one fact: LDH> information is missing. nothing more, nothing less. LDH> see also rule 3 of Ted Codd's 12 rules.
I'd personally like to see extensions to SQL to handle these subtleties.
LDH> Oh no, don't go there :-) LDH> Ted Codd tried this in his RM version 2, proposing A-marks and I-marks, LDH> and came up with an associated four-valued logic. LDH> the truth tables look horrible, and it does not solve anything...
Imagining a null-less database: Two options:
LDH> yep, the "default value" alternative approach. LDH> this can only be implemented on the concept of strong domains -- LDH> but unfortunately domains have never been implemented by the vendors LDH> (at least not by Oracle)
but wait, sometimes there *is* no value that could never be real for a given
column, so we'll have to add whole extra Boolean columns for each such
no-longer-nullable column to handle specifying whether we really ought to be
ignoring the value in that other column over there, and we build special
logic
into the application to handle refering to these special Boolean
pseudo-null-indicating columns almost everywhere we refer to the
no-longer-allowed-null columns,...
LDH> why? can't you represent this by a special value too? LDH> (maybe I am missing your point here) LDH> anyway, additional logic should NOT be built into the applications, LDH> but rather in the methods that are associated with the domains.
but wait, what about the column that starts out seemingly safe for designating, say, "-1" as the special "does not apply" value, but ends up in some special case needing "-1" for a *real* value - WHOOPS, I guess we better revert to another value, or to the special Boolean pseudo-null-indicating columns, and we'll have to fix all that special logic that formerly did special handling on "-1",...
LDH> sounds like a serious design mistake to me; LDH> don't get me started about serious RDBMS design mistakes :-)
But wait, what about the column that starts out seeming not to *need* "does not apply" or "we don't know", but later is discovered to ocasionally need this feature - WHOOPS, I guess we'll have to go back and change all the application logic
LDH> ditto -- and note that this logic should NOT be in the applications
Sure, nulls are confusing, and associated with all sorts of logic problems, but those problems are largely *inherent* in the underlying logical problem...
LDH> nulls would be much less confusing if they were implemented PROPERLY LDH> however, the SQL language certainly does not help here...
Imagine that you want data from bar-code readers at a supermarket to go straight into a database.
LDH> the "famous" cat food example ;-) LDH> I think this is already the wrong way to start; LDH> why insist that this data should go straight into the database? LDH> this looks like a transaction design mistake to me. LDH> what if the customer wants to cancel (forgot his wallet)?Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.htmlReceived on Fri May 28 2004 - 04:59:45 CDT
-----------------------------------------------------------------
 |
 |