mium
Drop #28··Advanced Query
advanced query (datalog)

Advanced Query (Datalog)

Eine Simple Query filtert eine Property. Datalog verknüpft viele — über Blöcke hinweg, mit Ableitung und Aggregat, zum Multi-Kriterien-Report.

Team Mut··baut mium··Falktron, Oelde
tl;dr··30 sek
  • ··Datalog ist eine Regel-Sprache: Du beschreibst, was wahr sein soll, nicht wie gesucht wird.
  • ··Regeln verknüpfen Blöcke über mehrere Kriterien, leiten Neues ab und aggregieren — eine Filterzeile kann das nicht.
  • ··Einmal definiert, wird die Regel zur wiederverwendbaren Sicht — der Report baut sich selbst.
audio··3:00
▶ Audio folgt
Transkript

Was, wenn Dein Report nicht aus zehn Sichten zusammengeklickt werden muss, sondern aus einer einzigen Regel entsteht — einer Regel, die beschreibt, was zählt, und sich von selbst neu rechnet? In den nächsten Minuten hörst Du, wo die Filterzeile endet und wo Datalog beginnt.

Eine Simple Query filtert eine Property und wird zur Sicht. Das reicht, solange Du eine Sache prüfst. Aber sobald Du zwei Dinge verbinden willst — offene Aufgaben aus den Meetings eines Quartals, gruppiert nach Projekt — endet die Filterzeile. Sie prüft Blöcke einzeln gegen feste Kriterien, sie verbindet nichts, sie leitet nichts ab, sie rechnet nichts zusammen.

Datalog dreht das um. Du beschreibst nicht den Suchweg, sondern das Ziel. Du sagst, was wahr sein soll, und überlässt der Engine das Wie. Das ist der Kern jeder deklarativen Sprache, und in der Datenbank-Forschung ist dieser Vorteil seit den Grundlagen der Datalog-Theorie konsistent dokumentiert.

Eine Regel hat zwei Teile. Das eine Stück sagt, welche Größe Du sehen willst. Das andere listet die Bedingungen, Zeile für Zeile. Variablen verbinden die Zeilen — taucht dieselbe Variable mehrfach auf, ist das ein Join, eine Brücke über Blöcke hinweg. Genau hier wird aus einer Filterzeile ein verknüpfter Report.

Drei Bausteine tragen Dich weit. Erstens beschreibt die Regel das Ziel, nicht den Weg. Zweitens ist jede Bedingungszeile ein Kriterium, und gemeinsame Variablen verbinden sie zum Join. Drittens verdichten Aggregate die Treffermenge — Du zählst, summierst, gruppierst, und aus vielen Blöcken wird eine Zahl je Gruppe.

Diese Mächtigkeit hat einen Preis. Eine unbeschränkte oder rekursive Regel kann den ganzen Bestand mehrfach durchlaufen. Setze Grenzen, prüfe das Tempo, und speichere eine Regel erst dann als Dauer-Sicht, wenn sie schnell genug bleibt. Und ohne saubere Properties greift keine Regel — die Datenpflege bleibt die stille Voraussetzung.

Die ehrliche Frage zum Schluss: Wie viele Deiner Reports baust Du jede Woche neu, weil sie mehrere Kriterien verbinden, die keine Filterzeile fassen kann? Liegt die Zahl hoch, zahlt sich die steilere Lernkurve aus. Einmal als Regel beschrieben, baut Dein Zweitgehirn den Report — und hält ihn aktuell, während Du denkst.

reels··3–15 sek
6,1K
Regel statt Filter
9,3K
Join über Blöcke
11,7K
count··sum··group
14,2K
Report baut sich selbst

Eine Simple Query filtert eine Property und wird zur Sicht. Aber sobald Du zwei Dinge verbinden willst — offene Aufgaben aus den Meetings eines Quartals, gruppiert nach Projekt — endet die Filterzeile. Datalog beginnt genau dort: Du beschreibst die Beziehung als Regel, und mium leitet den Rest ab.

Wo die Filterzeile endet

Eine Filterzeile prüft Blöcke einzeln gegen feste Kriterien. Sie kann nicht über Blöcke hinweg verbinden, nichts ableiten und nichts zusammenrechnen. Multi-Kriterien-Reports klickst Du sonst aus mehreren Sichten von Hand zusammen — und pflegst sie ebenso. Datalog dreht das um: eine Regel, die Beziehungen beschreibt, und eine Engine, die sie auswertet.

Anatomie einer Regel

Eine Datalog-Regel hat zwei Teile: :find sagt, welche Größe Du sehen willst, :where listet die Bedingungen — je Zeile eine. Variablen wie ?task verbinden die Zeilen; taucht dieselbe Variable mehrfach auf, ist das ein 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 ?m

5 Bausteine für Advanced Query

  1. Die Regel beschreibt das Ziel (:find), nicht den Suchweg — Du sagst was, nicht wie.
  2. Jede :where-Zeile ist eine Bedingung; gemeinsame Variablen verbinden sie zum Join.
  3. Aggregate verdichten: count, sum, max, min, avg über die Treffermenge.
  4. Eine Regel ist wiederverwendbar — benenne sie, und sie wird zur Sicht für das ganze Team.
  5. Grenzen setzen: rekursive oder unbeschränkte Joins brauchen ein Limit, sonst wird die Auswertung teuer.

Beispiel: offene Aufgaben je Projekt zählen

[:find ?projekt (count ?task)
 :where
 [?task "type" "task"]
 [?task "status" "offen"]
 [?task "projekt" ?projekt]]
;; ein Report: pro Projekt die Zahl offener Aufgaben

Vorher/Nachher — Simple Query vs. Datalog

FähigkeitSimple QueryDatalog
Kriterieneine Propertybeliebig viele
Über Blöcke verbindenneinja (Join über Variablen)
Ableiten / aggregierenneincount··sum··group
Wiederverwendbarals Sichtals benannte Regel
LernkurveMinutensteiler, dafür mächtiger

Ehrliche Frage

Wie viele Deiner Reports baust Du jede Woche neu, weil sie mehrere Kriterien verbinden, die keine Filterzeile fassen kann? Die Antwort entscheidet, ob sich die steilere Lernkurve von Datalog für Dich auszahlt — oder ob eine Simple Query schon reicht.

Beschreib, was zählt — den Rest rechnet mium.
Eine Regel, und Dein Zweitgehirn baut den Report — und hält ihn aktuell, während Du denkst. Kein Export, kein Zusammenklicken; ein Begleiter, der Deine Kriterien versteht.
Slot sichern··kostenlos →
Slot sichern··kostenlos →
Die Frühjahrsschule ist vorbei. Tag 93 ansehen → Das Spiel starten →