Hacker News Reader

Comment by mbreese | Hacker News Reader

Couldn't you just model your data in a traditional RDBMS with a time stamp as well? In fact for mutable data that you'd like to keep old versions of, this is pretty standard. A simple design would be to have a separate table for person_locations that mapped a person to a location.

With everything else, the standard RDBMS table could be considered as having a 'snapshot' of the Datomic values.

I'm still not sure what benefit this has over a traditional DB. Perhaps I'll just have to wait for the next post.

View on HN

You can do it all yourself if you want, but Datomic does it for you without you having to do anything.

Also as it does it on a datom level it is a lot more efficient than versioned rows.

Interestingly one of the early selling points of Postgresql was this time travel functionality. But it was yanked out in 6.2

http://www.postgresql.org/docs/6.3/interactive/c0503.htm

Yes, but you also loose the flexibility of not doing it. I'd rather work in an established RDMBS and configure in the design I'd like to use rather than use a database that requires a specific configuration.

I'm sure that Datomic has it's place, but the examples you gave in this post aren't that convincing.

I agree with you this is not on its own necessarily a good reason to switch to Datomic.

I will be getting into more detailed examples later. My real point with this post was more to talk about how to model the data using datoms and not specifically the temporal aspects of it.

I made many mistakes in my original data models in datomic based on many years of rdbms thinking.

The difference between Datomic and RDBMS isn't JUST a timestamp FYI. In fact I'd expect/hope this blog post is a just a prelude to Datomic's transactional model which is the real differentiator.

Absolutely. That is where I'm going in the next article. The transactions are extremely cool.

I look forward to it.

Of course you can make something similar if you're a) willing to build it and 2) don't care about the tremendous amount of complexity you're adding to your application in order to do so.

Both of those sound like bad deals if there's a packaged solution like Datomic that's built specifically for the use case.

Yes, you can do similar in a traditional RDMS, you have a table called Person and another table called Person_properties with a schema of pid, property, value, timestamp. The object model for Person would have a save() and load() method that knows which properties belong to the base table (base properties) and which properties spill over in into the triple table. The separate properties table has the convenience of stashing arbitrary persistent properties in a Person without needing to migrate the underlying schema or change the base definition.

Reply on news.ycombinator.com