>
>
> This is from an application design perspective, not while you a creating a
> table or constructing an insert statement.
I do not think it is possible to design an application not caring about the
data model it relies on.
And I am sorry if "people like me who write the code need to add 'IS NOT
NULL' to every conditional statement in our logic."
If you control your code, after retrieving the values from the database ,
you should have something like this:
if ($row['temperature'] != 9999) { ....this values are reallly good....}
you just moved the NULL values handling from the database to the
application.
also "everyone in the SQL world" would really love to have always all the
information on everything,
but it seems that it is not always possible.
> So instead of thinking that I am an idiot, try using your intelligence and
> try to understand what I am really talking about!
>
Now, if you really want this conversation to be constructive, just reflect
on this statement:
Your fake 9999 value for you has the same use of NULL, you just do not like
the NULL handling syntax.
Trying to use my intelligence I can only cite you the Codd third rule:
*Rule 3:* *Systematic treatment of null values*:
The DBMS must allow each field to remain null (or empty). Specifically, it
must support a representation of "missing information and inapplicable
information" that is
systematic<http://en.wikipedia.org/w/index.php?title=Systematic&action=edit&redlink=1>,
distinct from all regular values (for example, "distinct from zero or any
other number", in the case of numeric values), and independent of data
type<http://en.wikipedia.org/wiki/Data_type>.
It is also implied that such representations must be manipulated by the DBMS
in a systematic way.
If you are wondering who Codd is I can anticipate you that he invented the
things we are talking about
(http://en.wikipedia.org/wiki/Edgar_F._Codd)
Cheers
Claudio Nanni
