Modeling
A Widget has 1 or more Gadgets
A Widget has 1 or more Gizmos
A Widget has 1 or more Sprockets
Use Case
When the Widget is “in assembly”, it has an indeterminant number of Gadgets, Gizmos, and Sprockets components. Information on these components may be changed WITHOUT changing information on the Widget.
As such, it seems most appropriate for me to use the Document Reference pattern.
HOWEVER - once the Widget has been fully assembled, ALL details are frozen.
In this case, is it overkill to, upon “fully assembled” status, to delete the documents in the Gadgets/Gizmos/Sprockets collections and embed those documents on the Widget document? Document size is never going to be an issue - we’re talking about under 100 KB for the aggregate- and that’s being very generous on size.
To restate my question, in case the example isn’t clear:
Given a set of collections which reference a parent collection - once a series of actions is finished, the data for the document represented in the parent collection, and the documents in its child collections, will become read-only.
Does it make sense, in this case, to delete the child documents and embed them onto the parent document? Is this overkill? Could it make my database more performant to keep the number of documents in the child collections to a minimum?
Optimizing your schema for your access patterns after a certain processing is always welcome.
It is acceptable to have one pattern while assembling a list and then combining the list into a single document.
My question will be what prevents you from embedding the parts in the parent document at first? Is it the complexity of operations against it or the concern for a single document level locking?
I would love to use the embedded pattern from the beginning.
Take this case:
During assembly, N Gizmos may be added to the Widget.
Then, Gizmo[0] may have a property that needs to be changed: say from {color: “blue”} to {color: “green”}
I was under the impression that, given the dynamic nature of the child documents that it would be better to use the reference pattern so only the related document (or sub-document, in the case of the embedded pattern) would be updated.
In other words - my reasoning is that with embedded I would be running:
UPDATE Widget.Gizmo[0].color
whereas with reference, I would runL:
UPDATE Gizmo[].color
Pavel,
While working on something else, I stumbled on this guide:
I actually didn’t know this was a thing! I’m pretty sure this is going to be the best of both worlds. Is this what you had in mind with your question?
My question will be what prevents you from embedding the parts in the parent document at first? Is it the complexity of operations against it or the concern for a single document level locking?
