the more i see people speak about databases this way, the more i learn to appreciate chris date
almost all the explanations i've seen of datomic explain the software architecture or component (check this for example http://www.datomic.com/overview.html)
the more important aspect of a db is the conceptual data model, the abstraction it offer , the one which you as a developer will use to describe , create and query data and information
the relational model is not about the components of a DBDMS, its not about indexes, and optimizer, its about describing your data as relations, using relational operators and is even more primarily about data integrity
if it is not an implementation of the relational model, what is the model its trying to implement, and why should we use this data model?
I think partly this is because Clojure programmers already understand the ideas behind Datomic's data model, since it is somewhat of a natural extension of Clojure's model of state.
Rich has given talks on the architecture and talks on the data model, and at the Conj Stuart gave a talk on the testing infrastructure. You might poke around for a different talk if you haven't found one that touches on it yet.
I feel the same way about Datomic too. I really want to be excited about datomic, but I just can't. Rich Hickey is a smart dude, no doubt, but I just don't see anything amazing here with datomic. Every time I try to learn about what kinds of problems it solves, all I can find are descriptions of how different it works under the hood, how different it works from the perspective of the programmer.
To me the ability to be able to easily recreate the state, any state the DB was in at any time is much more important.
A big part of my job consist in asking DBA a dump of the production DB to PREPROD or DEV environments so that I can try to recreate the state at which the shit hit the fan. And it's more than painful. And it's not my fault: I'm inheriting apps that I have to maintain/bugfix/enhance. And it's hell. Mutability hell.
One day CRUD DB shall be regarded as dumbly as languages in which any variable can be globally modified, from any thread. We'll look back at these CRUD DB and wonder how stupid we've been not to listen earlier to the ones advocating a saner world.
You really should listen to several of Rich Hickey's talk because his ideas are more than sound and comes from a lot of Real-World [TM] immense pain suffering.
All the time he says: "Have you ever ...? Not fun!" he's 100% on spot. He's language and DB are the most pragmatic things ever.
Conceptually this is not so different than a regular database and its log. The log is the immutable, write-only part, and the tables are the current representation. Datomic moves the current representation further up the stack.
You can implement an immutable database system with SQL databases today. For instance, just design your application to only add new records, and not to issue any updates.
Datomic does a lot more than just avoiding updates/deletes. It splits the database into multiple parts. The transactor doesn't do any data storage. The clients handle all their own query locally. This means that the transactor (the only bottleneck in the system) does not have to handle any queries or storage and can spend 100% of its time handling write transactions. All other components of the system are trivially cacheable and scalable.
The other big advantage is the concept of "the database as a value". As a client, you can easily obtain the database as an immutable value right inside your application. This allows you to do all the queries you want without affecting anyone else.
You can right now rewind a database to an arbitrary point in time right off the transaction log. The feature exists in the technology, the vendors just haven't productized it. What does that tell you? That the demand for your use case is commercially insignificant.
almost all the explanations i've seen of datomic explain the software architecture or component (check this for example http://www.datomic.com/overview.html)
the more important aspect of a db is the conceptual data model, the abstraction it offer , the one which you as a developer will use to describe , create and query data and information
the relational model is not about the components of a DBDMS, its not about indexes, and optimizer, its about describing your data as relations, using relational operators and is even more primarily about data integrity
if it is not an implementation of the relational model, what is the model its trying to implement, and why should we use this data model?