Queries

A query asks the database a question and gets rows back. You ask in plain words, and the assistant or agent does the rest. This page explains the kinds of questions a database answers, so you can ask precisely and judge the answer.

The examples use these two tables:

customers

orders

Filtering

A filter keeps only the rows that match a condition, and a query can return just the columns you need. "Show the id and total of the paid orders" gives:

Conditions can check for:

• An exact value, or anything except that value.
• A number or date above, below or between two values.
• Any value from a list, such as paid or shipped.
• Text that starts with or contains something.
• Whether a value is empty.

You can combine conditions with and, or and not, such as "paid orders over 100 from March".

Sorting and paging

A query can sort its result and return only part of it. "Show the two largest orders" gives:

Rows have no fixed order of their own, so if order matters, ask for it. "The latest orders" only means something when the database knows to sort by date.

Totals and grouping

A query can turn many rows into one value: a count, a sum, an average, a smallest or a largest value. It can also group rows and calculate these once for each group. "How many orders has each customer placed, and what is their total?" gives:

It matters whether a filter applies to the rows or to the result. "Totals of paid orders per customer" leaves out unpaid orders before adding up, while "customers who spent more than 100" adds everything up and then keeps the large totals.

Joins

A join combines rows from two tables by matching a foreign key to the key it points to. "Who placed each order?" needs both tables, because the name is in customers and the total is in orders:

A join normally returns only rows that have a match on both sides, so Chloe, who has no orders, isn't in the result.

Keeping rows without a match

A join can also keep every row of one table, even when the other table has no match. Ask for it explicitly: "How many orders has each customer placed, including customers with none?" gives:

If a total or a list looks too short, check whether rows without a match were left out.

Finding rows with no match

The same idea finds broken links. Links between tables aren't checked, so ask now and then: "Are there any orders whose customer no longer exists?"

Empty values

An empty value means "unknown", which leads to some surprising results:

• "Customers in Dublin" doesn't include Chloe, as you would expect, but neither does "customers not in Dublin". Her city is unknown, so she matches neither. To include her, ask for "customers not in Dublin, including those with no city".
• Sums and averages skip empty values, so an average is taken only over the rows that have a value.
• A count of rows and a count of values can differ: three customers, but only two cities.

If a filtered result seems to be missing rows, empty values are a likely cause.

Asking good questions

A precise question gets a precise answer:

• Say what counts. Does "revenue" include open orders, or only paid ones?
• Name the period. Dates and times in the database are in UTC, so if "today" means your local day, say which time zone you mean.
• Ask for totals rather than lists. "Revenue per month" answers more than a list of every order.
• Ask how the answer was worked out if a number looks wrong. Each query appears in the chat with its tool call, and the assistant can walk you through it.

Queries in Tunori

To browse without a chat, open Data on the Database page.

A few limits apply to every query:

• Reading only. A query can't change anything. Changes go through separate tools.
• At most 200 rows per call, or 50 if the query doesn't ask for more. Agents page through larger results, and very wide results are cut shorter.
• 10 seconds per query. A slower query is stopped. An index is often the fix.