> "find two friends with same birthdays that also have cars of same color"
Wasn't that always a simple thing to do, e.g. in SQL?
And how about monitoring changes in the database based on a query? Is that possible and efficient?
Wasn't that always a simple thing to do, e.g. in SQL?
And how about monitoring changes in the database based on a query? Is that possible and efficient?
You don't do any string mungling, your query is itself composed of data structures. You can build it easily with code, so your queries become as elaborate as you can generate them.
Unlike SQL tables that you have to figure out from start, the data model is a collection of facts, with each fact consisting of {entity_id, attribute, value, transaction_info}. By adding facts to database you build the knowledge about entities and different relations between entities in an organic way. You can still use the table model, or you can use graph model.
The whole DB is just a value in memory. You can transit it to server, store history copies in memory (for undo/redo), do diffs, whatever you need.
As for monitoring changes, I'm using the Posh lib (also mentioned in article). It monitors the DB and re-renders react component if there are transactions relevant to component's queries. It seems very efficient so far, but I still have to test it with large number of components and transactions.
Interesting. Do you know if, upon a change, it reruns the queries from scratch, or does it update the results based on the actual changes?
For truly reactive datalog subscriptions, let's see what happens with clj-3df project. Unlike Datascript, it requires you to use server infrastructure right from start.
Something like: WITH stuff AS ( SELECT bday, carcolor, ROW_NUMBER() OVER ( PARTITION BY bday,carcolor ORDER BY bday,carcolor ) rownum FROM friends ) SELECT * FROM stuff WHERE rownum > 1;
select f1.id, f2.id from friends f1, friends f2 where f1.bday = f2.bday and f1.carcolor = f2.carcolor and f1.id > f2.id;
Similarly, don't expect that a single data model will suffice for all needs in an application. Expect to have to maintain anything that is useful.
Even having them in several tables is not rocket science, OP was just trying to give an easy example of types of queries that are easier with datomic than with sql.
Yes, this is a large part of why we use databases. They will do most of this heavy lifting. However, I don't think it changes the game. If you want some access to be easy or quick, you have to maintain the data in that format.