Advanced Query (Datalog)
When one filter line is not enough — rules that link, derive and condense
- You read a Datalog rule and name :find, :where and the join. ·· Success criterion: You explain, on a given rule, which variable forms the join.
- You write a rule that links two criteria across blocks. ·· Success criterion: Your rule returns the expected result set from two conditions.
- You condense a result set with an aggregate. ·· Success criterion: You group with count and get one number per group.
A Simple Query filters one property and becomes a view. But the moment you want to connect two things — open tasks from a quarter's meetings, grouped by project — the filter line runs out. Datalog begins exactly there: you describe the relationship as a rule, and mium derives the rest.
Where the filter line ends
A filter line checks blocks one by one against fixed criteria. It cannot link across blocks, derive nothing and add nothing up. Otherwise you click multi-criteria reports together by hand from several views — and maintain them the same way. Datalog turns this around: one rule that describes relationships, and an engine that evaluates it.
Anatomy of a rule
A Datalog rule has two parts: :find says which quantity you want to see, :where lists the conditions — one per line. Variables like ?task connect the lines; when the same variable appears more than once, that is a join.
[:find ?task
:where
[?task "type" "task"]
[?task "status" "offen"]
[?task "von-meeting" ?m]
[?m "tag" "q3"]]
;; offene Aufgaben aus Q3-Meetings — ein Join über ?m5 building blocks for Advanced Query
- The rule describes the goal (:find), not the search path — you say what, not how.
- Every :where line is a condition; shared variables connect them into a join.
- Aggregates condense: count, sum, max, min, avg across the result set.
- A rule is reusable — name it, and it becomes a view for the whole team.
- Set limits: recursive or unbounded joins need a limit, otherwise the evaluation gets expensive.
Example: counting open tasks per project
[:find ?projekt (count ?task)
:where
[?task "type" "task"]
[?task "status" "offen"]
[?task "projekt" ?projekt]]
;; ein Report: pro Projekt die Zahl offener AufgabenBefore/After — Simple Query vs. Datalog
| Capability | Simple Query | Datalog |
|---|---|---|
| Criteria | one property | any number |
| Link across blocks | no | yes (join over variables) |
| Derive / aggregate | no | count··sum··group |
| Reusable | as a view | as a named rule |
| Learning curve | minutes | steeper, but more powerful |
An honest question
How many of your reports do you rebuild every week because they link several criteria that no filter line can hold? The answer decides whether Datalog's steeper learning curve pays off for you — or whether a Simple Query is already enough.
- Take a report you click together by hand from several views today. Write out, in words, which quantity you want to see at the end and which conditions have to be true for it — one condition per line. Then translate that into a Datalog rule with :find and :where, and name the variable that forms the join.⏱ 5 min
💡 Start with the quantity you want after :find and write the :where lines only afterwards. The variable that appears in two lines is your join — mark it first.
Model answer: After :find stands the quantity you want to see, say the task or the project. Below it you put one :where line per condition: type is task, status is open, and through the meeting variable the task hangs on a quarter's meeting. The same meeting variable in two lines is the join. For a count you wrap count around the task variable and group by the project — one number per project, with no export.
What can Datalog do that a Simple Query cannot?
Describe what counts — mium computes the rest.
One rule, and your second brain builds the report — and keeps it current while you think. No export, no clicking together; a companion that understands your criteria.
Reserve your slot··free of cost →