A document store is basically optimized for specifically hierarchal data situations — a tree. The data structure you’re describing, and what the article describes, is precisely that: a tree.
When comparing a document store versus a RDBMS, in terms of suitability and appropriateness, the distinction is primarily along the lines of a tree, versus an arbitrary graph (by which I mean that an RDBMS is more powerful, and more general, but not inherently as optimal in either performance, “scalability”, or UX in the places where a document store makes sense.
More specifically, the way the article describes it, you’re not interested in “give me every block of type X” — you’re only interested in “given block Y, what type is it?”.
That is, the question is one-way, and fits cleanly in a hierarchal format of a document store.
The only question posed that operates in the reverse direction is permissions, though even that’s a little odd, since it seems to me it should only go “downwards” as well — a block’s permission scope is the sum of all of its parents, and you can store it there upon iteration.
> The underlying persisted data doesn't necessarily have to be a bag of KV pairs.
It doesn’t have to be... but it can be, and appears to be.
> A block is related to its parent and descendant blocks.
Right; the singular parent, and the multiple children. A tree.
> In graph theory, a tree is an undirected, connected and acyclic graph.
When discussing trees and graphs, I think it’s obvious a distinction is being made between a graph forming a tree, and graph forming a not-tree (more complex than a tree). When I say that a square is easier to encode than a rectangle, I do not mean that a square is not a rectangle, but that a rectangle is not a square — that a square’s more specific properties give us opportunity to simplify/optimize (I only need to store one length to represent it).
A database can encode a tree just fine, but that doesn’t mean it’s the best tool to do so.
There are other properties to a document store I don’t care for, and I don’t like them in general (like the implicit schema, and total lack of data consistency validation by the data store, and the fact that you often don’t truly have a tree), but representing a tree is what’s been described, and it’s exactly what they’re specialized for.
If you want to argue against it, you need to specify why you think this isn’t a tree, because I feel it’s quite obvious it is.
When comparing a document store versus a RDBMS, in terms of suitability and appropriateness, the distinction is primarily along the lines of a tree, versus an arbitrary graph (by which I mean that an RDBMS is more powerful, and more general, but not inherently as optimal in either performance, “scalability”, or UX in the places where a document store makes sense.
More specifically, the way the article describes it, you’re not interested in “give me every block of type X” — you’re only interested in “given block Y, what type is it?”.
That is, the question is one-way, and fits cleanly in a hierarchal format of a document store.
The only question posed that operates in the reverse direction is permissions, though even that’s a little odd, since it seems to me it should only go “downwards” as well — a block’s permission scope is the sum of all of its parents, and you can store it there upon iteration.
> The underlying persisted data doesn't necessarily have to be a bag of KV pairs.
It doesn’t have to be... but it can be, and appears to be.
> A block is related to its parent and descendant blocks.
Right; the singular parent, and the multiple children. A tree.
> In graph theory, a tree is an undirected, connected and acyclic graph.
When discussing trees and graphs, I think it’s obvious a distinction is being made between a graph forming a tree, and graph forming a not-tree (more complex than a tree). When I say that a square is easier to encode than a rectangle, I do not mean that a square is not a rectangle, but that a rectangle is not a square — that a square’s more specific properties give us opportunity to simplify/optimize (I only need to store one length to represent it).
A database can encode a tree just fine, but that doesn’t mean it’s the best tool to do so.
There are other properties to a document store I don’t care for, and I don’t like them in general (like the implicit schema, and total lack of data consistency validation by the data store, and the fact that you often don’t truly have a tree), but representing a tree is what’s been described, and it’s exactly what they’re specialized for.
If you want to argue against it, you need to specify why you think this isn’t a tree, because I feel it’s quite obvious it is.