The advantage is that that can be somebody else's job though, and ideally (eventually) an AI's job.
1,513 karma · joined August 24, 2015
[ my public key: https://keybase.io/refset; my proof: https://keybase.io/refset/sigs/pyTK0thu8g5O4Zs7EA3HrQYKkYZjeEz_TUr8nZV2hlY ] c0ba44896414421c9009bc8a77a86ceb
meet.hn/city/51.0612766,-1.3131692/Winchester
Socials: - github.com/refset
---
The advantage is that that can be somebody else's job though, and ideally (eventually) an AI's job.
Not sure on your definition of 'people', but I think every business ultimately wants solid auditing and reporting capabilities across their IT systems.
These concerns are only increasing in importance as new regulations demand stronger data provenance, but their implementation shouldn't be reliant on the process of "proper schema design" to get things right first time.
Databases built for the modern world should be making this stuff bulletproof and easy.
(I work on XTDB - and if Postgres already supported temporal tables I possibly wouldn't!)
But system-time is only half the story. There has been chatter over the years on the PG mailing lists, but there doesn't seem to be much momentum currently towards adding full SQL:2011 bitemporal support to Postgres. Adding support in a way that feels as natural as using Datomic seems unlikely.
Datomic is actually only 'uni-temporal', it provides a database-wide, immutable "system time" (aka "transaction time") versioning + very effective as-of querying. This naturally falls out of the "Epochal Time Model" (see Deconstructing the Database, 2012). However there is no particular built-in support for any further mutable time dimension, see: https://vvvvalvalval.github.io/posts/2017-07-08-Datomic-this...
System-time is still very powerful though. The way I think of the difference is: system-time versioning is mainly useful for debugging and auditing (and of course for the horizontal read scaling), whereas valid-time versioning is useful for timestamp-based reporting (or other forms of in-application time-travel and modelling 'truth' in business data) where the system-time timestamps are not the timestamps end users are directly interested in, see: https://tidyfirst.substack.com/p/eventual-business-consisten...
And without the ORM layer there's this extension for Postgres: https://github.com/hettie-d/pg_bitemporal
Until that's the case I can understand why people are tempted to bypass this traditional RDBMS wisdom, especially if they have a very strong conception about their data models, access patterns, and need for scale (e.g. see also Red Planet Labs 'Rama').
XTDB may possibly of interest in that case - there's been some recent chatter about adding support for Ecto via Postgres compatibility: https://discuss.xtdb.com/t/elixir-ecto-thread-from-slack/490
(I work on XTDB)
Rich's observation was that query optimizers often get things wrong in ways that are hard to predict or control, but he's not fundamentally opposed to their use. That said, building a decent optimizer is a huge undertaking and I think they took the right decision to not attempt to bundle that sort of complexity into the original vision for Datomic otherwise they might never have shipped.
The state-of-the-art commercial engine for query optimization and execution algorithms in this 'triple' space is probably https://relational.ai/
> Functional relational programming for Clojure(Script).
> For the last nine years, PostgreSQL’s “serializable” mode has justifiably claimed to offer serializability.
> [but] PostgreSQL’s “serializable” isolation level isn’t serializable: it allows G2-item during normal operation
> [...] These cycles are precisely what PostgreSQL’s SSI implementation is meant to prevent!
> This code has gone essentially untouched since the introduction of serializable snapshot isolation in 2011.
Making things appear to be serializable is really hard.
> Unlike most database management systems (DBMS), Project:M36 is opinionated software which adheres strictly to the mathematics of the relational algebra. The purpose of this adherence is to prove that software which implements mathematically-sound design principles reaps benefits in the form of code clarity, consistency, performance, and future-proofing.
> Project:M36 can be used as an in-process or remote DBMS.
> Project:M36 is written entirely in the Haskell programming language.
If I were to attempt a summary myself... RVBBIT is a SQL-powered relational programming canvas with a visual Clojure REPL and full-stack UI framework.
#1 would be the lack of a production ready DBaaS (like Aurora offers for Postgres), if I had to guess.
> "Political activity is whatever shifts a body from the place assigned to it or changes a place's destination." (Rancière 1999, S. 30)
> What Rancière means by that is that politics occurs whenever a thing is not in its assigned place. This is perfectly valid for software: As soon as a person diverts from what is expected from them, software aborts with an error or "corrects" the "wrong" statement automatically. So at least from the view of Jacques Rancière, software is utterly political. It has a significant impact on our daily lives and we cannot do anything against this. And this is a problem that especially corporate software shows.
https://www.zettlr.com/post/release-developing-open-source-p...
> it seems very possible to go from #1 -> #2 mechanically, and hand that off to the users who want to play with it
NocoDB seems like a reasonable attempt of taking this approach for Postgres.
Really impressive stuff - congratulations!
Related, I rather enjoyed reading this other thread from June: "Ask HN: Is KDB a sane choice for a datalake in 2024?" https://news.ycombinator.com/item?id=40625800