« It has been demonstrated ad nauseum in database literature. »
Yeah, I know it has been and it's still be demonstrated and discussed as
nauseum in database literature and that quite probably in the foreseable
future that they will keep doing so. I also know that it's very easy to
*prove* that any set of values associated with the null value can be
replaced with the association of this same set of values less the null value
and a flag value.
So what? Are these people who are living in their ivory tower also doing my
work and paying my bills?
People are not so stupid and tend to keep with them things that they find
useful while dropping other things that may be considered by others as
beeing theoritically better but a more of an hindrance than anything else
when you have to use them in the real world.
All this theory might look good on paper but when it comes to design your
interface with the users, that's another story. I'm more concerned with the
later than with the former.
--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail:
http://cerbermail.com/?QugbLEWINF
Sylvain said:
« "All in all Nulls are a pain and SQL and the products only make it
worse.
I would always *try* to avoid them, Nulls that is (g), with careful
database
design. The way they are implemented from product to product and from
version to version could easily vary. This, markers idea, was a mistake by
Codd, IMHO, and the vendors and ANSI jumped on it and we seem to be stuck
with it for now." »
This is a big statement and we often read something similar to this,
written
in one way or another. However, there is absolutely no example, proof or
demonstration behind it to back it or to substantiate it. When you want
to
write a statement about something, you must come with a least a little
more
in order to support it.
It has been demonstrated ad nauseum in database literature. Date,
Darwen and Pascal for example. The proof is the principles violated and
the logic that cannot be reconciled with nulls, not just isolated
examples.
I could give you a lot of examples where the use of NULL leads to a
clearer
code, with less fuss and easier to read. However, I won't because this is
a
case where personal experience is more important than dogmatic statements.
NULL is like any other tools, you must learn how to use it properly and if
you want don't know about it or don't want to use it, that's your problem,
not the other's.
In my case, I like to have more tools in my toolbox, not less: when the
only
tool you have in your toolbox is an hammer, everything else looks like a
nail and inversely, when all you have to do is to hit a nail, every tool
begins to look like a hammer.
The toolbox analogy implies that you have a choice. Many SQL
implementations make it unreasonably hard to avoid nulls, but that's a
deficiency of SQL, not an advantage of nulls. Not everyone gets to
choose what data model and DBMS to work with.
--
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--