| > I guess the intention is to be better than SQL but then I was left with "under which circumstances?". The way I see it, SQL's great strength as a query language is selection and projection whereas Datalog's great strength is inference. It takes a shift in mindset to take advantage of inference. I've started using Datalog when analyzing unfamiliar codebases. So I might set up something like: writes_to(microservice1, db1).
writes_to(microservice2, microservice1).
writes_to(microservice3, microservice2).
depends_on(X, Y) :- writes_to(X, Z), depends_on(Z, Y).
depends_on(X, Y) :- writes_to(X, Y).
Allowing you to query something like: depends_on(microservice3, X)
and get back db1, microservice1 and microservice2. Of course, you can ultimately do this in SQL as well, but it's far more compact in Datalog.Which brings me to the second half of the motivation - the principal advantage to the logical database model is the open world assumption. The relational model in practice tends to be fairly buttoned down - data is expected to suit a particular schema (which has its own advantages as a transactional system). This makes it easy to extend a logical database and ask more questions without changing the fact formats already specified. Of course, I can ultimately do all the things that feel natural in Datalog in SQL. I can work through queries like the one above by building out the data model and writing recursive CTEs. It's about strengths, not possibilities which I suppose brings me back to why SQL 'won'. A disproportionate amount of code is written for transactional line-of-business systems. It's really not hard to see why the validation layer and transactional focus would win in those areas. |