3 ms·

This article is not good. Event Sourcing and the Relational Model are orthogonal. SQL:2011 added a lot of temporal features. Datomic is based on Datalog which

by alecco 3y ago

This article is not good. Event Sourcing and the Relational Model are orthogonal. SQL:2011 added a lot of temporal features. Datomic is based on Datalog which even though is not relational it's kind of the same, and has temporal support. [2] [1] https://en.wikipedia.org/wiki/SQL:2011 https://en.wikipedia.org/wiki/SQL:2011 [2] https://vvvvalvalval.github.io/posts/2018-11-12-datomic-event-sourcing-without-the-hassle.html https://vvvvalvalval.github.io/posts/2018-11-12-datomic-even... (BTW 24 points at the top of HN and no comments? Hmm)

nomoreusernames 3y ago
[dead]
ithkuil 3y ago
Datalog is relational in the original sense of relational algebra.
- alecco 3y ago
  Sure. But the point of the article is for Document or Object-Oriented. And the specific points would apply to Datalog, too. My point was you can do the equivalent of Event Sourcing with SQL and even better with Datomic. > In Event Sourcing Church, we’re not doing that anymore. We’re not losing business data; we keep them. We keep them as events.
cmrdporcupine 3y ago
Datalog is definitely relational. More so than SQL. In terms of temporal data handling & relational & Datalog, it's worth looking at Differential Datalog: https://github.com/vmware/differential-datalog https://github.com/vmware/differential-datalog
refset 3y ago
> Datomic [...] has temporal support Note it only supports "transaction time" (or "system time" per SQL:2011) but not "valid time" (~"event time") which is needed for a bitemporal data model. [1] [1] https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this-is-not-the-history-youre-looking-for.html https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this...
hot_gril 3y ago
You don't need specific temporal support for an event-oriented DB, nor would I want it. I usually design a vanilla relational schema around events regardless of which DBMS I'm using. E.g. instead of an "order" table with multiple states updated in-place, I'd have "order_placed" and "order_filled" where each row is an event, insert-only.
deleted 3y ago
[deleted]

by alecco 3y ago

nomoreusernames 3y ago

[dead]

ithkuil 3y ago

Datalog is relational in the original sense of relational algebra.

alecco 3y ago
Sure. But the point of the article is for Document or Object-Oriented. And the specific points would apply to Datalog, too. My point was you can do the equivalent of Event Sourcing with SQL and even better with Datomic. > In Event Sourcing Church, we’re not doing that anymore. We’re not losing business data; we keep them. We keep them as events.

cmrdporcupine 3y ago

Datalog is definitely relational. More so than SQL. In terms of temporal data handling & relational & Datalog, it's worth looking at Differential Datalog: https://github.com/vmware/differential-datalog https://github.com/vmware/differential-datalog

refset 3y ago

> Datomic [...] has temporal support Note it only supports "transaction time" (or "system time" per SQL:2011) but not "valid time" (~"event time") which is needed for a bitemporal data model. [1] [1] https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this-is-not-the-history-youre-looking-for.html https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this...

hot_gril 3y ago

You don't need specific temporal support for an event-oriented DB, nor would I want it. I usually design a vanilla relational schema around events regardless of which DBMS I'm using. E.g. instead of an "order" table with multiple states updated in-place, I'd have "order_placed" and "order_filled" where each row is an event, insert-only.

deleted 3y ago

[deleted]