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: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql?unsub=arch...@jab.org
