Database tables, keys and queries

Understand the record shape and relationships before connecting them to a page.

A table stores one kind of record

A products table might contain id, name and price. Each row is one product; each column describes one value. Choose types that represent the value you need to store, rather than treating every field as display text.

Use a stable primary key

The id identifies one product even when its name changes. An edit or delete action should receive that key, validate it and restrict which matching record the current user may modify. A product name is a poor substitute for a stable key.

Relationships connect records

An order_items record can contain order_id and product_id to connect an order to its products. Database Manager lets you define supported relationships. A relationship describes how records connect; the server query still decides which fields and related records to return.

Queries return a chosen result

A query can select a subset of columns, filter records, sort them and limit the result count. Return only the data the page needs. An empty array means the query returned no rows; it is different from a failed database connection.

Keep credentials and checks on the server

Configure the database connection for the project target and use it from Server Connect. App Connect receives the action’s output, not database credentials. Validate submitted input and enforce access in the server action before reads or writes.

Check your result

You can distinguish a table, a record, a primary key, a related key and a query result.