Having looked quickly at it just now it seems (Wikipedia article) similar to Web Ontology Language (OWL), though I believe datalog may have been around long before owl.
Having looked quickly at it just now it seems (Wikipedia article) similar to Web Ontology Language (OWL), though I believe datalog may have been around long before owl.
The more interesting answer is to think of datalog as making it easy to encode nearly all of your application logic as a bunch of self-referencing, incrementally updated, materialized views. Some examples:
# view of Users table for currently logged in user
LoggedInUserView(name, email, id) :- Users(id:
payload["userId"], name, email), Cookies(name: "login", payload).
# view of Users for admin
AdminUserView(name, email, id) :- Users(id, name, email), Cookies(name: "login", payload), payload["isAdmin"] = true.
# posts a user can see
PostsView(title, content, id) :- Posts(title, content, public: true).
PostsView(title, content, id) :- Posts(title, content, author: payload["userId"]), Cookies(name: "login", payload).
And then you write your UI code to explicitly reference these derived views rather than manually wrapping an API around querying the Posts table and doing the filtering.The examples above can be neatly replicated in Supabase or Postgraphile (the OG of auto-generated GraphQL over Postgres), but you can do a lot more with datalog as a language. The Hellerstein paper mentioned above is a good starting place.
Is this SQL query similar to the first datalog query you listed? I apologize for how HN formatted the below and my lack of understanding for how to get around it.
Select u.name, u.email, u.id From Users u Join Cookies c on u.name = c.name
create view LoggedInUserView as
select u.id as id, u.name as name, u.email as email
from Users u
join Cookies c on c.name = 'login' and u.id = c.payload->>'userId';
where payload is a json blob. (Indent code by 2+ spaces.)Most people wouldn't design their schema in a SQL database like this with a bunch of special-use relations/views, but datalog encourages you to do so since defining a new relation is the only means of abstraction. In effect, you've created an API endpoint similar to /api/auth/users and, what's more, you can use the LoggedInUserView in other rules to define new relations.
> The intersection of databases, logic, and artificial intelligence gave raise to deductive databases. Deductive database systems are database management systems built around a logical model of data, and their query languages allow expressing logical queries. A deductive database system includes procedures for defining deductive rules which can infer information (in the so-called intensional database) in addition to the facts loaded in the (so-called extensional) database. The logic model for deductive databases is closely related to the relational model and, in particular, with the domain relational calculus. Datalog is the most known deductive query language (which syntactically is a Prolog subset) where constructed terms are not allowed as other non-declarative constructs such as the cut.
> Also following the relational model, relational database systems are well-known and widespread nowadays. Their formal query languages include relational algebra and relational calculi but, in practical systems, the de-facto and ANSI/ISO standard SQL is the language of choice of every relational database vendor. Whilst SQL and relational formal languages implement a limited form of logic, deductive database languages implement advanced forms of logic.
https://www.fdi.ucm.es/profesor/fernan/des/html/manual/manua...