#SQL

Chirps tagged with #SQL

dbt Charts introduces an open-source, declarative approach that treats dashboards as code—living alongside dbt models so they can be version-controlled, reviewed in pull requests, and validated just like data transformations. By combining #SQL and YAML, humans and AI agents can collaboratively build, modify, and ship trustworthy visualizations that stay in sync when underlying models change. This gives AI the governed context it needs to produce reliable answers while extending analytics engineering practices all the way through the BI layer.

Sample chart definition using #SQL and YAML:


queries:
  revenue_by_month:
    #sql: |
      SELECT date_trunc('month', ordered_at) AS month,
             sum(product_price) AS revenue
      FROM MY_DATABASE.MY_SCHEMA.order_items
      GROUP BY 1
      ORDER BY 1

charts:
  revenue_trend:
    type: line
    query: revenue_by_month
    x: month
    y: revenue
    title: "Revenue by month"
https://www.getdbt.com/resources/webinars/introducing-dbt-charts-dashboards-as-code

Open Graph Image
www.getdbt.com

Introducing dbt Charts: Dashboards as code | dbt Labs

See how dbt Charts brings dashboards as code to your workflow, giving humans and AI governed context to build, review, and ship trusted dashboards.

LLM-generated TypeQL queries reach higher final accuracy than #SQL or Cypher once retries are permitted, because TypeDB’s strong type system converts most mistakes into clear, visible errors the model can fix, whereas #SQL failures frequently return silent wrong answers that go undetected. On the Reactome pathway database, TypeQL accuracy climbed from 75 % to 92 % with a modest retry budget while MySQL moved only from 82 % to 83 %, leaving TypeQL the most reliable choice for agentic systems that rely on error feedback.

https://typedb.com/blog/why-llm-written-typeql-can-end-up-more-accurate-than-sql-once-you-allow-retries

Open Graph Image
typedb.com

Why LLM-written TypeQL can end up more accurate than SQL once you allow retries

Comparing LLM failure modes across MySQL, Neo4j and TypeDB on the Reactome pathway database, and why retries make TypeDB queries so much more accurate.

HawDB is an embedded graph database built in Rust that enables applications to efficiently store, query, and explore connected data using native Cypher and #PostgreSQL-compatible #SQL. It combines query optimization, reliable ACID transactions with crash recovery, optional full-text and vector search, and graph analytics in a lightweight, configurable package that runs directly within an application. Developers can experiment with the online playground

https://hawdb.ai/playground/

hawdb.ai

Playground — HawDB

A real terminal for HawDB: type Cypher or SQL, press Enter, see the result. Runs entirely in your browser via an experimental wasm32 build.

This analysis set out to test the common but under-proven intuition that a strong type system helps LLM agents produce more correct results, running a controlled benchmark that kept the AI model, underlying dataset and set of test questions consistent while swapping between the #SQL, Cypher and TypeQL query languages to isolate this effect. While #SQL had the highest single-shot success rate, TypeQL’s robust type checker caused 93% of its incorrect queries to throw clear visible errors, compared to just 5% for #SQL and 40% for Cypher, and when paired with a simple retry loop that feeds these errors back to the LLM to fix, TypeQL ultimately achieved the highest overall query accuracy.

https://typedb.com/blog/benchmarking-llm-query-generation-across-sql-cypher-and-typeql

Open Graph Image
typedb.com

Benchmarking LLM query generation across SQL, Cypher and TypeQL

Explore our new LLM benchmark comparing MySQL, Neo4j, and TypeDB. Learn how context and retry budgets help AI agents self-correct and improve performance.

Detecting V-shaped stock price reversals in standard #SQL is cumbersome because it requires comparing neighboring rows, grouping consecutive price movements, and filtering those groups to identify the pattern. MATCH_RECOGNIZE simplifies this by letting you define the V-shaped trend directly as a sequence of pattern states, making the analysis more concise and intuitive.

https://www.databricks.com/blog/regex-rows-simplifying-pattern-detection-sql-matchrecognize

Open Graph Image
www.databricks.com

Simplifying Pattern Detection with MATCH_RECOGNIZE | Databricks Blog

Databricks solves complex sequence detection with MATCH_RECOGNIZE, bringing regex-style pattern matching to relational data, without self-joins or chained CTEs.

← Newer Page 1 of 3 Older →