Creating Sub Tables
Model nested one-to-many data with sub tables, understand what Wappler generates, and know how that structure feeds nested queries later.
Introduction
Section titled “Introduction”Sub tables are the Database Manager feature for modeling nested one-to-many data directly in your schema. Use them when one record naturally owns a list of child records, such as a project with tasks, a contact with phone numbers, or a blog post with comments, and you want Wappler to keep that structure recognizable all the way into later queries and updates.
Start from the parent table you want to own the children
Section titled “Start from the parent table you want to own the children”A sub table is created from the parent side, not from a random standalone table. Think first about which record should own the child collection. That ownership decision shapes the data model, the generated foreign key, and how the nested records will appear later in Query Builder and output schemas.
Create the sub table from the parent context
Section titled “Create the sub table from the parent context”The Database Manager creates sub tables as part of the parent table structure, so the action belongs on the parent table context. That is the important mental model: you are not just creating another table, you are declaring a child collection that hangs off a specific parent record.
What Wappler generates for you
Section titled “What Wappler generates for you”Wappler handles the repetitive relational plumbing that usually makes nested data feel manual. It creates the child table structure, keeps the parent-child relationship explicit, and presents that child table under the parent in the manager so the nesting is visible instead of buried in database details.
Why sub tables matter later in Query Builder
Section titled “Why sub tables matter later in Query Builder”The payoff comes after the schema step. In Database Query Builder and related server actions, sub tables appear as nested children under the parent table, so a single query can return the parent record together with its child collection. That is why sub tables are more than a schema convenience: they shape the data output model used by the rest of the stack.
Next steps
Section titled “Next steps”Continue with the next layer of relational modeling. If you need many-to-many relations, switch to Multi References. If you want to see how nested structures are selected in actions, continue into database query tours. Otherwise return to the Database Manager recipe hub for another schema task.