3 ms·
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 o
by niftich 10y 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.
- MBCook 10y agoRight. 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".
- cdevs 10y agoBut my middle name IS null
- firethief 10y agoIn other words, you don't have a middle name. Not to be confused with: > But my middle name IS "null"
- pwg 10y agoAnd 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.
- petemill 10y agoYour answer is entirely correct. This should be the top comment.