Comment by niftich
9 years ago
I entirely agree with your point with regard to a fixed-schema, row-based, relational-like datastore. But in a KV-store like DynamoDB, there's a different set of possibilities:
[1] key present, value undefined or null or some other special type
[2] key present, value is empty object of its expected type
[3] key absent
In schemaless datastores where the value's content somehow determines its datatype, it can be difficult to enforce a distinction between scenarios [1] and [2]. Meanwhile, in an externally-schema'd datastore (like most RDBMS), you don't have option [3]. I am familiar with the practice of mapping "we don't have a known-good value for this" to omitting the key in an KV-store, while in an RDBMS that semantic meaning is mapped to a NULL instead.
Right. In Dynamo you could store JSON with "middleName: null" and know that means "We asked, they didn't have it" as opposed to a record without a middleName key which means "we never asked".
And now you've just discovered why relational databases have a "null" concept that is separate from the "empty string" concept.
In a relational table, all rows in the table have a "middleName" column. So you can't "omit" the column entirely for some rows like you can in a doc/KV store.
"NULL" in a relational DB is to store, in a table where every record has a "middleName" column, the concept of "missing key" from a key/value store type layout.
NULL is the relational DB's way of representing: "a record without a middleName key" exists here.
But my middle name IS null
In other words, you don't have a middle name. Not to be confused with:
> But my middle name IS "null"
Your answer is entirely correct. This should be the top comment.