You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm interested in the key-value conclusion. If the data is highly structured, e.g. tabular or hierarchical, then I imagine that a key might be "row x column y", or for (e.g. JSON) document data, a key might be "person.addresses.home.street_number". This could potentially make the storage quite inefficient/expensive.
I think that as long as
changesets can refer to the smallest atoms of data,
they can be reliably applied in forward/reverse direction as required
then storing the master version in (say) CSV or JSON format would be just as useful.
I'm interested in the key-value conclusion. If the data is highly structured, e.g. tabular or hierarchical, then I imagine that a key might be "row x column y", or for (e.g. JSON) document data, a key might be "person.addresses.home.street_number". This could potentially make the storage quite inefficient/expensive.
I think that as long as
then storing the master version in (say) CSV or JSON format would be just as useful.
I also wonder whether mentioning the "Command/Query Responsibility Segregation" (CQRS) and Event Sourcing patterns in the Review of Existing Tools and Approaches might be useful.
https://en.wikipedia.org/wiki/Command%E2%80%93query_separation
https://martinfowler.com/eaaDev/EventSourcing.html
These can be useful when it is important to be able to undo or reconstruct sequences of operations.
The text was updated successfully, but these errors were encountered: