On Dec 5, 2008, at 9:49 PM, Brad Hubbard wrote:
> Could you give me a brief example of a scenario where NULL would
> have special significance?
In SQL, NULL doesn't mean "empty", or 0. It is a value equal to
nothing else. It is often used to mean that a field does not have a
value, that it has never been set. It is possible in SQL to literally
give no value for a field when creating the row:
CREATE TABLE wilma...bla bla bla...
fred TINYINT UNSIGNED DEFAULT NULL,
barney TINYINT UNSIGNED NOT NULL
...bla bla bla
INSERT INTO wilma SET barney=5
The resulting row in the wilma table will have a NULL value for the
fred field, lacking a better one.
SQL NULL can also indicate indeterminacy. For a boolean field, this
would mean "maybe". For an integer field containing measured data, it
could mean "no reading taken here" such as due to equipment failure.
There are many uses for this concept.
If you have no special use for SQL NULL, you shouldn't set that
attribute in the table definition.
> I was under the impression that Null<foo> should be used wherever
> Null was set to "yes" in the database schema and, therefore in
> theory at least, that field could potentially be null.
That's right, but the question is not whether Null<> goes with SQL
NULL. The question is whether you have a legitimate need for SQL NULL
in the first place. If you don't need it, you can save yourself all
this hassle by dropping it.
>> If you can't change the DB, use the NullIsBlank behavior. If you do
>> that, the code can be:
> I could change the DB so that the filed can't be null and must just
> be an empty string, I could also use NullIsBlank.
The NullIsBlank and NullIsZero behaviors cause MySQL++ to pretend SQL
NULL isn't a unique value, causing it to silently convert to either a
blank string or integer 0, respectively. These behaviors are useful
in cases where you can't get rid of the NULL attribute on the column,
or NULL just doesn't have meaning in a certain context but does have
meaning in others. If your application has no special use for NULL
and you can change the DB, change the DB.
>> something_that_requires_a_c_string = sql_char(it-
>> You need the explicit conversion in there because C++ won't
>> implicitly do two casts in a row.
> Understand, would I be better off using static_cast<sql_char>(it-
> >mobileNumber).c_str() ?
Only substitute static_cast for (this_type)of_cast, never for
this_type(of_conversion). The latter isn't actually a cast at all.
It's a call to a class's conversion constructor, which is a pure C++
way of converting values from one type to another, and is always
safe. It is not brute-force like a C-style cast. It only compiles if
the class has an appropriate conversion constructor; if it does, the
class is saying the conversion is legitimate.
> I am not sure I grasp the concept of "significant nulls" at the
That's probably because your thinking is stunted by C/C++'s use of
NULL, which is not a unique value; it's equal to 0 in integer
context. Many other languages have something like SQL NULL, a value