Projektowanie tabel z AI

A table is a named list of similar things. A "users" table holds users; a "posts" table holds posts.

Each table has columns that define what facts you store, and each row is one item. Modeling means deciding which tables and columns your app needs.

Every column has a type: text, number, boolean, date, and so on. Types keep your data clean. An age column should be a number, not free text.

When you describe a table to your AI, it will suggest sensible types, but you can review and correct them.

Every row needs a unique label so you can find it again. That's the primary key, usually an auto-incrementing id or a generated UUID.

Without it, two identical rows are impossible to tell apart. Your AI will normally add an id column automatically.

You don't have to write schema syntax yourself. Describe the table plainly and let the AI translate it.

Be specific about each field's meaning, and the generated schema will match your intent closely.

Real apps have related data: a user has many orders. We connect them with a foreign key, a column in one table that points to a row's id in another.

Describing the relationship in plain words lets the AI add the correct keys for you.

A user having many orders is one-to-many. But a student taking many courses, where each course has many students, is many-to-many and needs a joining table.

Naming the relationship type, or just describing it, helps the AI build the right structure.

Some fields must always be filled, like an email for an account. Others can be blank, like a middle name. We mark these as not null or nullable.

Spelling out which fields are required prevents broken records later, so include that detail in your prompt.

If you find the same value copied across many rows, like a category name typed out every time, that's a sign to split it into its own table.

This is called normalization. Ask the AI to review your design and flag repeated data.

Once you have a few tables, it helps to see how they connect. Ask the AI to describe the relationships as a simple diagram in text.

This catches missing links or wrong directions before you write any save-and-read code.

Your schema will change as the app grows. A migration is a recorded change to the database structure, like adding a column.

Ask the AI to generate migrations rather than editing tables by hand, so every change is tracked and reversible.

The schema is the foundation; fixing it later is harder than fixing it now. Always read the AI's proposed tables before approving.

Check the names, types, keys, and relationships. A few minutes of review saves hours of cleanup.

Test your understanding of modeling tables with AI.

Tables are lists with typed columns, each row identified by a primary key. Foreign keys connect tables, and you choose between one-to-many and many-to-many relationships.

Describe tables in plain words, mark required fields, normalize repeated data, and use migrations for changes. Always review the AI's schema before building. Next, you'll save and read records.