Tables and a database for your mini app: schema, relations, import

What you do right on the schema

1. 1

   Every table is a card

   A card lists every column with a type icon, plus the row count. Relations are drawn as crow’s-foot lines: many events, one venue.

2. 2

   Relations are dragged

   Drag the dot on the right of a table onto another table and a relation column appears. Click the line to point it at another table or delete it.

3. 3

   Columns are edited on the card

   Name, type, Enter — the column is there. Columns are reordered and deleted in the same place, and a double-click renames the table.

4. 4

   Rows open below

   The selected table opens in full under the schema: records, columns, import from a file or a Google Sheet, and export.

5. 5

   The layout stays

   Cards are moved with the mouse and their positions are saved in the project. Arrange lays everything out by itself.

6. 6

   Undo, and a phone

   Every action on the schema undoes with Ctrl/⌘+Z. On a phone the schema opens full screen and zooms with a pinch.

Who writes into a table from the app

Each table has its own write mode, and that mode decides whether a visitor sees anyone else’s rows.

• Only me and editors

  A catalogue, a price list, a timetable: visitors read, you edit — in the editor or from a phone inside the app.

• Everyone writes their own

  A cart, favourites, “my bookings”: a row is seen only by the person who wrote it.

• Everyone writes, everyone sees

  Reviews and listings: a row is visible to anyone who opens the app.

• Everyone writes their own, the admin sees all

  Requests handled by someone other than the owner: the appointed admin sees every record in that table.

Why relations rather than one big sheet

In a listings app an event happens at a venue, in a shop a product sits in a section, in a school a lesson belongs to a course. Keep it all in one sheet and the venue’s address repeats in every event row — and changing it means changing it in twenty places. A relation stores it once: the event row holds a link to the venue, and the screen shows its name and address.

That is what the schema is for: seeing which tables a project has and how they point at each other without opening them one by one. With five or six tables it saves more time than it sounds.

The same tables that draw the screens

The schema is not a separate program or a copy. These are the same tables a repeater draws lists from, that forms write requests into and actions write rows into. “Show these records on the screen” drops a list onto the open screen that displays every record of the selected table by itself.

A formula column is computed from the other columns of the same row and is never filled in by hand. The tables are reachable inside the app too: the owner and editors add and edit rows from a phone without opening the editor.

Data can be brought in rather than typed

Import takes CSV and XLSX — an export from Google Sheets, Yandex Tables, Excel or 1C. The file is read right in the browser; columns are matched in a preview, and rows are appended or replace everything. You can also paste cells copied straight from a spreadsheet.

Export gives the table back as a CSV file: fix it in Excel, import it again, and the columns are recognised by name. If the data already lives in a Google Sheet, on Yandex Disk or in your own system behind an address that returns JSON, the table can be connected to it as a source — there is a separate guide on that.

The limits, stated plainly

• Rows typed in the editor reach the app when you press Publish. What visitors write from inside the app appears at once.
• How many records you can keep depends on the plan. The ceiling is checked on write, so it is better known in advance.
• Rows from a connected Google Sheet are edited in the sheet itself: an edit made in the editor is lost at the next refresh of the source.
• This is not SQL: there are no queries, indexes or joins of your own. Filters, search and sorting are set on the list on a screen.
• A visitor writing “their own” row needs your bot connected: the person is identified by your bot’s signature, and without it there is no proving whose row it is.

Questions people ask

Does a mini app need its own database or server?

No. The tables are stored in the project alongside the app, on the platform’s servers. If the data already lives in your own system, connect it through an address that returns JSON — no second copy to keep.

How do I relate two tables?

In the Data mode, drag the dot on the right of one table onto another. The first gets a Relation column: many of its rows point at one row of the second — many events at one venue, for instance. Clicking the relation line points it at another table or deletes it.

Can I bring data over from Excel or Google Sheets?

Yes. Drop a CSV or XLSX into the import window and match the columns in the preview. A Google Sheet need not be copied at all: connect it as a live source and the app re-reads it on a schedule and at publish time.

Which column types are there?

Text, number, yes/no, image, icon, video, file, date, date and time, time, random code, select, multi-select, relation to another table, and formula.

Does the schema work on a phone?

Yes. On a phone it opens full screen and zooms with a pinch, and a table row is edited as a card rather than a wide grid.

Will visitors see each other’s records?

The table’s mode decides. With “everyone writes their own” a row is seen only by its author — that is how a cart and an order history work. Reviews use “everyone writes, everyone sees”.

What if I delete a column by accident?

Ctrl/⌘+Z brings it back: every action on the schema undoes — a deleted column, a deleted relation, a moved card.