The temporal aspect seems to be somewhat ignored by mainstream db development - in some fields, e.g. BI you'll have slowly changing dimensions; and the event sourcing pattern promises a time-machine view on data.
Since I'm writing a history-aware application at the moment, I recently looked into different patterns for this and trying a mixed strategy at the moment (SQL DB used as document store and a single event log, that accumulates changes - a lean approach though, a few hundred lines python for the data access layer; what always gets ugly is the validation, which your application must take care of).
I wish, there was more hands-on material on the subject (some resources dive depth into bi-temporal modeling, but I feel your schemas can get complex (= expensive) very fast).
Big Data by Nathan Marz is a Manning Early Acces book (i.e. not fully written yet) that explains how to hand-roll your own custom Datomic style DB in Hadoop/HBase.
It might be of interest to you given your current project.
Thanks for the tip, will take a look at it. Probably after this project, the current app must be lean (no big dependencies, just install a database scheme, pip install and go).
by my understanding, datomic's persistence[1] layer is just a big huge persistent[2] data structure. there is tons of literature, books, papers, etc about persistent data structures in the functional programming community.
Acid-State for haskell (http://acid-state.seize.it/) is based on a similar ideology and in the public domain. (Oh, but minus the time dimension I'm afraid.)
Acid-State is quite different, it persists representations of operations to disk (to make it durable) and keeps the data structure in memory.
I'm working on a project to bring persistent data-structures to disk ( https://github.com/DanielWaterworth/Siege ). It's currently undergoing a rethink, hence the lack of recent activity, but it's still in development.
This case study tried to be somewhat rigorous, but from what I recall the SQL did get complex and expensive pretty quickly. There are a few attempts to create products to mask the complexity as well:
kdb+ is head and shoulders about the rest when it comes to introducing time / order into relational data. It's lean, minimalistic and ridiculously fast.
It's also easy to bring to its knees with seemingly innocent queries, and has a pretty darn opaque programmable interface in Q. (OK, the vaguely SQL-like stuff is not too hard, once you understand the differences from normal SQL, but doing anything lower level than that is awesome/crazy)
Since I'm writing a history-aware application at the moment, I recently looked into different patterns for this and trying a mixed strategy at the moment (SQL DB used as document store and a single event log, that accumulates changes - a lean approach though, a few hundred lines python for the data access layer; what always gets ugly is the validation, which your application must take care of).
I wish, there was more hands-on material on the subject (some resources dive depth into bi-temporal modeling, but I feel your schemas can get complex (= expensive) very fast).