Notation für SQL-Bedingungen in JSON-Strings

Kompakte String-Notation für SQL-Bedingungen aus JSON

Beim Erstellen von SQL-Abfragen aus JSON-Dateien landen Sie oft bei langen Bedingungsausdrücken. Der ursprüngliche Ansatz nutzte Arrays wie "vendor_id": [17,-23], die in vendor_id = 17 OR NOT vendor_id = 23 umgewandelt wurden. Das ist knapp, aber begrenzt – keine Unterstützung für Bereiche, MIN/MAX-Aggregationen und mehrdeutige Syntax.

Die neue Notation löst das mit einem String-Format, das per regulären Ausdrücken validiert wird. Sie deckt Vergleiche, Mengen, Bereiche und Negationen für alle Datentypen mit =, <, >, ! Operatoren ab. Das Minuszeichen steht für logische Negation, unabhängig vom Datentyp.

Kernkonstrukte der Notation

Die Notation wandelt Strings wie X=operand in Standard-SQL um. Sie unterstützt binäre Funktionen wie MIN, MAX und BETWEEN.

X=y        -> X = y
X<y        -> X < y
X>y        -> X > y

X!=y       -> X < y OR X > y
X<=y       -> X < y OR X = y
X>=y       -> X > y OR X = y

Für Zweier-Mengen:

X=[y1, y2]     -> (X = y1 OR X = y2)
X>[y1, y2]     -> (X > MAX(y1, y2))
X<[y1, y2]     -> (X < MIN(y1, y2))

X!=[y1, y2]    -> (X != y1 AND X != y2)
X<=[y1, y2]    -> (X <= MIN(y1, y2))
X>=[y1, y2]    -> (X >= MAX(y1, y2))

X>>[y1, y2]    -> BETWEEN(y1, y2)
X><[y1, y2]    -> (NOT BETWEEN(y1, y2))

Für Mengen beliebiger Größe gilt dieselbe Logik: OR für Gleichheiten, AND für Negationen, MIN/MAX für Grenzen.

Vorteile gegenüber Arrays

Der Wechsel von JSON-Arrays zu Strings vereinfacht Parsing und Validierung:

• Validierung: Reguläre Ausdrücke statt Schema-Prüfungen pro Element.
• Vollständigkeit: Eingebauter Support für Bereiche und Aggregationen – keine Erweiterungen nötig.
• Lesbarkeit: Nutzt mathematische Intuition – X>[y1,y2] bedeutet X größer als alle Elemente.

Beispiel für Kürzung:

Traditionelles SQL: WHERE (age >= 18 AND age <= 65) OR age > 70

Notation: age>=[18,65] OR age>70

Bewertung durch KI-Modelle

Die Analyse von DeepSeek hebt die Stärken hervor:

• Kompaktheit: Hohe Informationsdichte ohne Bedeutungverlust.
• Intuitivität: X!=[y1,y2] bedeutet eindeutig ungleich allen.
• Erweiterbarkeit: Einfach Bereiche mit >> (inklusiv) und >< (exklusiv) hinzufügen.

Mögliche Probleme:

• Mehrdeutigkeit für Einsteiger: X>[5,10] erfordert Verständnis von MAX.
• Leere Mengen: Verhalten für X=[] definieren.
• Konflikte: >> könnte mit Bitverschiebungen kollidieren.

Verbesserungsvorschläge:

• Alternativen für Bereiche: X..[y1,y2], X:[y1,y2].
• Klammern für strenge Bereiche: X>>(10,20).

Analoge und Einzigartigkeit

Ähnlichste Analoge:

| Sprache/DSL | Beispiel | Ähnlichkeit |

|-------------|-------------------------|-----------------------------|

| Quist | 300 <= number < 500 | Doppelvergleiche, Mengen |

| SQL++ | lang IN ["en", "de"]| IN für Arrays |

| PRQL | derive full_name = ...| Funktionaler Ansatz |

Einzigartigkeit der Notation:

• Pfeile >>, >< für BETWEEN/NOT BETWEEN.
• Kombinationen wie >=[y1,y2] für Mengengrenzen.
• Minimalismus mit voller Expressivität.

Vergleich:

• Notation: age>=[18,65] OR status=[active,pending]
• Quist: (18 <= age <= 65 OR status:in active, pending)
• SQL: (age >= 18 AND age <= 65) OR status IN ('active', 'pending')

Wichtige Erkenntnisse

• Entwickelt für SQL-Preprocessoren oder JSON-DSLs im Backend.
• Regex-basiertes Parsing: Schnell, keine komplexen Parser nötig.
• Unterstützt alle vergleichbaren Datentypen.
• Logisches Minus für Negationen vereinfacht die Einheitlichkeit.
• Erste Version zur Diskussion – noch keine Optimierungen.

— Editorial Team