Data can be arranged relationally. When you order data with relationships in mind, it can be important to know what type of data we’re talking about.
Data types can be many things; numeric, integer, floating point, text, binary, dates, times, addresses — data types can be anything a database daemon was designed to support.
A problem can arise when you have a data container that is empty, awaiting data. For example, if your data type is integer, you may believe that a 0 represents nothing. But a zero represents a 0, not nothing, even though a 0 can represent nothing to us. Some databases might automatically place a 0 in a data container if no other value was provided. Other databases might not be so bold and reckless.
The problem is more apparent when considering text, or strings. If your container is meant to contain a string, yet you find yourself with no string to put in it, you have to ask yourself a question: “is the fact that I have nothing to put in it purposefully nothing – an empty string – or is it instead that it is an unknown, or undefined?”
Consider being told that you will have something done for you on Thursday. That’s great. It fits nicely in the date container. However, the Tuesday before, when you re-query the person, you find out that it may or may not happen on Thursday. If that confluence between a date and an event were to be filled, should it be an empty value, or an undefined (NULL) value?
Really, it depends upon the person who may or may not show on Thursday. Most people would say not to even define an event until that event is a “real” event. You can always add or delete things at any time. But that takes measurable work, and it consumes resources, and you have no built-in way to know if it’s tentative or not – it either is, or it isn’t going to happen.
A null in this case is very good at stringing people along. The event will easily be update-able to be happening or not, yet will never cause a conflict with any other overlapping event because it has an undefined value – NULL.
Interestingly, database users still argue over the usefulness of nulls in databases. Opponents of nulls claim that nulls easily confuse people and that any facts of known, unknown, or undefined values should live in the logic of the program running, rather than in the structure of data reality.
On the other hand, proponents of nulls claim that nulls reflect the reality of experience, in that some data must have the potential to be undefined when it has not specifically been set, even to nothing — because in doing so you can then claim data related to that thing may also be unknown or undefined.
Unfortunately, the real reality is that people and their languages are not always the best at accommodating undefined things – whether they are the ones generating the undefined things, attempting to process them, or just simply to sensibly store them, in relation to any knowns.
Personally, I like nulls. Because they tell a story — and a fuller, richer one at that. Just keep in mind your own logic and language issues. Oh, and of course, those same things of others.