To be clear I'm not experienced enough to judge all these tradeoffs properly either, and I've never worked with Datomic. I suppose my main point is that an ideal database UX would avoid having to write processing/transformation code that needs to run outside the database (Clojure is pretty great, but still). This vision probably runs counter to the 'deconstructed' design of Datomic which heavily emphasises the usage of Clojure around it, but that could possibly be reconciled. It may well even barely register as a significant gap for current users in practice - I have no real idea :)
provide a set of logical views to isolate the application from the physical structural decisions
To me this feels like the holy grail for what people really want from databases (beyond the basics of transactions/durability), and triples definitely still hold promise as a helpful abstraction. However I suspect Incremental View Maintenance (as Relic discusses) has a potentially even bigger role to play here.
Comments
To be clear I'm not experienced enough to judge all these tradeoffs properly either, and I've never worked with Datomic. I suppose my main point is that an ideal database UX would avoid having to write processing/transformation code that needs to run outside the database (Clojure is pretty great, but still). This vision probably runs counter to the 'deconstructed' design of Datomic which heavily emphasises the usage of Clojure around it, but that could possibly be reconciled. It may well even barely register as a significant gap for current users in practice - I have no real idea :)
To me this feels like the holy grail for what people really want from databases (beyond the basics of transactions/durability), and triples definitely still hold promise as a helpful abstraction. However I suspect Incremental View Maintenance (as Relic discusses) has a potentially even bigger role to play here.