|
|
|
|
|
|
by karmakaze
1329 days ago
|
|
|
I can't tell which parts are agreeing or disagreeing with the quoted statements. Is doing versioning explicitly in a database necessarily more complicated than with git histories? Using a distributed datastore should make operations simpler and more transparent without having to think about the distributed nature, other than latency of operations. So if using a distributed datastore achieves distributed nature, is the tamper-evidence what's needed and missing or something else? For a cloud-based app, redundancy/fault-tolerance is the concern rather than being distributed unless you're running a globally distributed platform that can't be partitioned. Datomic/Datalog[0] is an example where the log of changes is the primary 'store' and a coherent view at any point in time is constructed from the log. [0] https://en.wikipedia.org/wiki/Datomic |
|
|
What "versioning" means depends heavily on the database. "Versioning" for typical relational databases like Postgres does not achieve many of expected git features like branching and ability to materialize data for arbitrary point in time, unless you build something extra on top (or just use db as git storage). There are databases like dolt where "versioning" idea is similar to git.
> is the tamper-evidence what's needed and missing or something else?
I always work in controlled environments, so don't care much about tamper-evidence (unless its used for detecting integrity issues perhaps).
I didn't know datomic, that's looks like solution for half of the problem (distribution and history). I may still be missing something more human-focused like git, where you have branches, collaboration and push or pull when needed.
I was just commenting, not disagreeing.