List:General Discussion« Previous MessageNext Message »
From:Johan De Meersman Date:March 14 2009 11:15pm
Subject:Re: Fwd: avoiding use of Nulls
View as plain text  
It's a good thing, then, that we've got your experience to rely on.
Woe is us, for not having any, and not seeing how obviously right you

You're entitled to your opionion on NULLs, but kindly stop spamming
*my* mailbox with it. I was aware of your dislike for them after the
first mail.

On Sat, Mar 14, 2009 at 8:24 AM,  <michael@stripped> wrote:
> Think!
> I'm not talking about how you application is designed. If your
> applications allows an employee to be entered without a position in the
> company, it is a bad design.
> If a manager at my company hired someone, and did not know what work the
> new-hire would be doing, well I'd really need to ask why they were hire,
> right before I fired the manager for hiring someone for no apparent
> reason.
> No fake row needed, a dept is required!
> So far the weather guy has the best example of using nulls, and again, I'd
> receive a null from the remote weather bug, but I wouldn't put that
> garbage in my database!
> I would NOT use -9999 for the missing dept, my application would flat-out
> require a department. If the data entry clerk wants to add some dummy
> department because they hire lots of people for no reason, then so be it.
> Better example anyone?
> And FAX numbers, what about home phone, not many of those lately either.
> Notice that phone numbers in general are an odd sort, especially because
> of the variant types around the world. So phone numbers should be strings,
> not numeric. Therefore I think blank spaces would be reality. Uh, whats
> there FAX number? It's blank. That means they don't have a FAX number. But
> if you decide to use Null, then in binary terms it is uninitialized
> garbage. It adds to your development time, your debugging time, and your
> processing time. Not to mention the possibility of inconsistent results
> when retrieving data. Same applies to middle names, you simply need to
> think about each field of data, and what it really means to the
> application.
> You guys who disagree on this: I know that this is what you were taught in
> school, and I know all the uses for null values. I just think the teaching
> is wrong. Sometimes teachers don't think, and most of the time students
> don't think. But when you become experienced, you should think.
> And finally:
>  The words of Tony Hoare: The man who developed the most widely used sort
> algorithm around the world.
> Tony said: "I call it my billion-dollar mistake. It was the invention of
> the null reference in 1965. At that time, I was designing the first
> comprehensive type system for references in an object oriented language
> (ALGOL W). My goal was to ensure that all use of references should be
> absolutely safe, with checking performed automatically by the compiler.
> But I couldn't resist the temptation to put in a null reference, simply
> because it was so easy to implement. This has led to innumerable errors,
> vulnerabilities, and system crashes, which have probably caused a billion
> dollars of pain and damage in the last forty years. "
> It's unbelievable that nobody agrees with me, or even sees my point,
> Mike.
>>  Exactly the point. Michael, NULL *is* information. It means "unknown" and
>> that is in itself useful information. A common example:
>> A new employee is hired but which department she will work in is unknown.
>> So
>> the data entry person enters all the known information and leaves the rest
>> until it has been clarified.
>> The alternative is even worse than the so-called NULL problem and the
>> alleged difficulty of querying against NULLable columns: in a case like
>> that
>> described above, the only way to handle it is to create a fake row in the
>> foreign-key table, for "Department Zero" or somesuch. That immediately
>> turns
>> every query into a more complex beast that it would otherwise have been.
>> Every single query must exclude this "zeroth" row; join a few tables all
>> exhibiting this problem and things get really crazy.
>> Not to mention the fact that these "zeroth" rows falsify reality and
>> combine
>> fiction with fact. Even worse, the "-99999" approach means that you can't
>> impose a constraint on the column (such as "must be a positive integer".
>> And finally, I cannot believe that you really mean "no NULLS ever". Surely
>> you mean only FKs. Otherwise, how would you handle fax numbers for people
>> with no fax, or middle names for people with none?
>> Arthur
> --
> MySQL General Mailing List
> For list archives:
> To unsubscribe:

Celsius is based on water temperature.
Fahrenheit is based on alcohol temperature.
Ergo, Fahrenheit is better than Celsius. QED.
Fwd: avoiding use of NullsArthur Fuller14 Mar
  • Re: Fwd: avoiding use of Nullsmichael14 Mar
    • Re: Fwd: avoiding use of NullsJohan De Meersman15 Mar
  • Re: Fwd: avoiding use of NullsChris W15 Mar