There is a difference between abusing a relational database versus using something that is key-value from the ground up.
Notice how in the example you have:
1 Name Ludic
1 Age 29
1 Profession Tortured Soul
The key is not unique. There is no primary key. So to hunt down all the properties of User 1, you have to do a query for all the records whose Key is 1.
I think that doesn't happen in keyword-value stores. Your key 1 has to be unique: it retrieves one blob, and that's it. You have to stuff all the properties into that blob somehow: for instance, by treating it as an array of the keys of other blobs.
Derek could have used multiple tables. That still gives you all the flexibility. Just that if someone wants to invent a new property, they have to add a table.
Then we have
Name table: Age table: Profession table:
1 Ludic 1 29 1 Tortured Soul
The keys are unique: we fetch key 1 from each table, and we have the three properties. Not great compared to fetching one row with three fields, but better than stuffing everything as rows into one table.
> I think that doesn't happen in keyword-value stores.
It absolutely does happen in triple stores, though, where data is commonly stored in subject-predicate-object form, and the subject's identifier is certainly meant to be unique to that subject, but not per triple.
> The key is not unique. There is no primary key. So to hunt down all the properties of User 1, you have to do a query for all the records whose Key is 1.
In this example, the primary key would be ([User ID],[Key]). The primary key does not need to be a single field.
It's not a bad thing on SSD storage maybe. On spinning platter hard drives, we may have to suffer a head seek time to get each field of the object from a separate record in the separate table. Whereas the fields of a record can be stored close together.
“Future users of large data banks must be
protected from having to know how the data is
organized in the machine (the internal
representation)… Activities of users at
terminals and most application programs
should remain unaffected when the internal
representation of data is changed and even
when some aspects of the external
representation are changed…”
Roll the related data up into materialized views for read performance.
Notice how in the example you have:
The key is not unique. There is no primary key. So to hunt down all the properties of User 1, you have to do a query for all the records whose Key is 1.I think that doesn't happen in keyword-value stores. Your key 1 has to be unique: it retrieves one blob, and that's it. You have to stuff all the properties into that blob somehow: for instance, by treating it as an array of the keys of other blobs.
Derek could have used multiple tables. That still gives you all the flexibility. Just that if someone wants to invent a new property, they have to add a table.
Then we have
The keys are unique: we fetch key 1 from each table, and we have the three properties. Not great compared to fetching one row with three fields, but better than stuffing everything as rows into one table.