Hi Dan, sorry, I could not resist -- see inline ... Kind regards, Lex. --------------------------------------------- visit my website at http://www.naturaljoin.nl --------------------------------------------- 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: 1) Everywhere you have column that would currently be nullable, declare, for that column, some *special* value to handle "we don't know" or "does not apply" (or perhaps two values...) 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)?
BEGIN:VCARD VERSION:2.1 N:de Haan;Lex FN:Lex de Haan ORG:Natural Join B.V. TEL;WORK;VOICE:+31.30.2515022 TEL;HOME;VOICE:+31.30.2518795 TEL;CELL;VOICE:+31.62.2955714 TEL;WORK;FAX:+31.30.2523366 ADR;WORK:;;Pieter Breughelstraat 10;Utrecht;;3583 SK;Netherlands LABEL;WORK;ENCODING=QUOTED-PRINTABLE:Pieter Breughelstraat 10=0D=0AUtrecht 3583 SK=0D=0ANetherlands URL;WORK:http://www.naturaljoin.nl EMAIL;PREF;INTERNET:lex.de.haan@xxxxxxxxxxxxxx REV:20040224T160439Z END:VCARD