28 min read

Asking Questions of Data

A query is a saved question: filter, sort, choose fields, and read current tables — without making a second copy of the facts.

Why ask the database?

The facts live in tables at Riverside Public Library in York. Staff still need answers. How many members live in York? Who has Northern Light out today? List every member from A to Z. You could read the whole Members table yourself. The software can answer for you. The named object that holds such a question is a query . A query is not another pile of copied phone numbers. It is a saved question . Each time you run it, it reads the current tables and returns a result . If Sophie Walsh moves from York to Bristol, the next run of "York members" will not include her. You did not edit a second list.

Stored data versus query result

Two different jobs

$Stored in the table$	$Shown in the result$
$Every member row, all cities$	$Only York members this run$
$Sophie's city after she moves to Bristol$	$She drops off the York list automatically$
$The official Members table$	$An answer sheet that is not a second store$

Stored data is what the library keeps in its tables. A query result is an answer produced right now from that stored data. Change a stored fact — Sophie's city, a return date — and the next run of a query that reads those tables gives a different answer. The result does not become a second official table.

Filter, sort, and choose fields

Most beginner questions are built from three moves. Filter. Keep only the rows that match a condition. City is York. ReturnDate is empty (book still out). Sort. Put the remaining rows in an order: FullName A-Z, or LoanDate newest first. Sorting does not change what is stored. Choose fields. You may only need FullName and Phone. The other columns still exist on the table. The query simply does not show them.

Result: members who live in York
Result: members who live in York

Filter kept City = York. Harry Cole (Bristol), Emily Brooks (Manchester), and James Ward (Leeds) are still in Members. They are not in this result.

Same query with sort and chosen fields
Same query with sort and chosen fields

Filter on City, sort by FullName A-Z, show only name and phone. MemberID and City are still stored — just hidden in this result.

A question that needs more than one table

"Who has Northern Light out?" cannot be answered from Members alone. The title lives in Books. The pairing lives in Loans. The query follows the relationships you designed: Loans.BookID matches Books.BookID, Loans.MemberID matches Members.MemberID. Names and titles are looked up, not recopied onto one wide sheet.

Result: who has Northern Light out
Result: who has Northern Light out

Name from Members. Title from Books. Date from Loans. ReturnDate is empty on loan 102, so the book is still out. Nothing new was stored.

A query reads. It does not replace the tables.

The result can be filtered, sorted, and trimmed to chosen fields. The official facts stay in the tables.

Calculated fields in the result

Sometimes the answer needs a value that is not stored on the table. The query calculates it when you run it. On Loans, LoanDate is stored. DaysOut might be calculated as today's date minus LoanDate. The result can show DaysOut, but the table does not gain a new column that staff must maintain. Calculated values belong in the result, not as a second copy of facts you should store once elsewhere — such as copying a phone onto every loan row.

Practice

Swipe or use the arrows to move between questions.

1 / 4

Staff need a list of York members every month. What should they build?

The official member facts live in Members. Nobody wants a second list that goes stale.

Which moves does this question need: "York members, A-Z, showing only name and phone"?

Select every move this question uses.

A query lists only York members. Sophie moves to Bristol. What happens on the next run?

Which parts of "Who has Northern Light out?" come from stored tables?

Select every stored fact the query reads.

More lessons in Database Fundamentals · Next: Indexing · Previous: Designing a Database