Hacker News Reader

Comment by mikkom | Hacker News Reader

I have a hard time understanding what problem this solves versus SQL?

This really should have demonstration of some of the actual use cases where this shines vs SQL.

Also: SQL-92 has values clause which makes the example provided a little bit silly, you could just use

    values (2),(3),(5)

Another example they gave is a 5-line (excluding imported code) mocking code with a comment "compare that to what you would have to do to achieve the same using bare SQL". Okay..

    select * from (values (1, 'hello'), (2, 'logic'), (3, 'programming')) as mocktable(user_id, comment);

View on HN

I guess the appeal of Datalog is the recursion that can be expressed in rules:

    has_descendant(?ancestor, ?descendant) :-
        has_child(?ancestor, ?child),
        has_descendant(?child, ?descendant).

Here, the assumption is that you have explicit `has_child` facts (expressing vertices in a graph, essentially), and the above rule gives you paths of arbitrary length.

In SQL, given a table has_child(parent, child), it is not clear to me how you can get all descendants of a given person, or all ancestors.

Other people talk about recursive extensions to SQL, maybe that provides a way.

Depends on the specific SQL flavor, e.g. https://www.postgresql.org/docs/9.1/queries-with.html

Logica instead seems to create tables and drop tables?

https://github.com/EvgSkv/logica/blob/main/examples/Logica_e...

It looks like Logica code isn't actually translated to a (large) SQL query, but Logica code is dynamically interpreted by some interpreter that calls into a SQL database as the virtual machine.

Not sure what Logica really provides here. Datalog usually comes with elaborate techniques to make sure only what's really needed is calculated instead of just generating all values every fact generation "iteration".

> It looks like Logica code isn't actually translated to a (large) SQL query, but Logica code is dynamically interpreted by some interpreter that calls into a SQL database as the virtual machine.

Actually, I might have jumped to a wrong conclusion. I really don't know if that's what happens here, but if not then it would imply that recursion isn't actually driven by the evaluation mechanism, but by Logica creating enough tables for a given program to ensure that iterative evaluation of rules ends up with a fixed point result set. Not quite sure. None of the other examples show recursion in the SQL output itself either.

Well, at any rate I'd like to learn more about the actual mechanism here but they are a bit light on documentation.

The normal SQL way is with a recursive CTE and help from the query optimizer. Differs more in feeling (constructing relations with joins vs. defining predicates with logic) than in substance from the Datalog way.

Sqlite official examples: https://sqlite.org/lang_with.html

MySql official examples: https://docs.oracle.com/cd/E17952_01/mysql-8.0-en/with.html

The problem Datalog tries to solve is complexity: SQL "pulls" data (what's a query after all) to a calling application. Datalog builds up data relationships through declarations. That means that: a) that entities can be inferred from these relationships as opposed to large complex queries, b) that some of these relationships can be built up by code/robots as opposed to humans declaring them.

The end result is (you hope) a very complex database where the smaller blocks/relationships can be audited and verified quickly, and where parallelization more or less comes for free.

The reality is that Datalog systems end up being massive hairballs of declarations that are hard to unravel for mere humans (well, regular developers) and that query-based solutions are 10x faster to develop for 80% of the application use cases.

The closest parallel is functional-vs-procedural programming (don't flame me); it's a niche solution for niche problems.

Source: former Datalog developer for ERP systems.

I actually mostly agree with you, except for the fact that in reality SQL is not a language, but a family of languages, some of which don't support the syntax[1], including Google's own BigQuery. Whether or not this is a reason to create a completely new unrelated language is still up for a debate.

Tangentially related, but does anybody know of a program or a library that takes standard SQL queries as input and outputs one or multiple equivalent queries using the SQL dialects of a set of DBMSs? That is, compiles a standard SQL query into a PostgreSQL one, an SQLite one, etc.

[1]: https://modern-sql.com/feature/values#compatibility

> does anybody know of a program or a library that takes standard SQL queries as input and outputs one or multiple equivalent queries using the SQL dialects of a set of DBMSs?

There are a number of tools that translate queries between SQL dialects. Google for “sql dialect translator”.

The thing is, most of them translate between dialects of SQL excluding Standard SQL, which is both more and less than what I would like to have. I don't want the ability to turn PostgreSQL SQL into SQLite SQL, but I do want the ability to turn Standard SQL into both of these. I guess, that will remain an idea for a hobby project, heh.

That's explained carefully in the first 5 paragraphs, especially paras 1, 3, 4, and 5.

Yes I read it. Lots of abstract talk about modularity and how SQL is so bad because people tend to use all caps without demonstrating how and what this whole new programming language can do better.

Note that I'm not claiming it can't do but I would be interested for the authors to point out what the actual benefits are.

All I see from their examples that clauses in Logica are much longer than SQL counterparts and that they are importing modules which (I assume) re-define already defined schemas which brings all kinds of different dependency problems that I'm not going to go in here..

The document assumes you have used SQL in anger before and run into it's lack of modularity. If you haven't run into those things then you'll miss the point. But if you have then this looks really interesting.

Ignore the upper caps thing. Have you not run into the problem that SQL cannot be written with reusable units of code? Do you not find reusable units of code to be the basis of programming?

Yeah, the quip about many people preferring to write SQL keywords in all caps as if that were somehow a defect of SQL struck me as being astonishingly asinine.

Reply on news.ycombinator.com