Enregistrer et lire des enregistrements

Almost everything an app does with data is one of four actions: Create, Read, Update, and Delete. Together they're called CRUD.

Once your tables exist, you'll ask the AI to write code for each of these, often one feature at a time.

To store something new, you insert a row into a table. The app collects the values, then writes them into the database.

Describe the data and the table, and let the AI generate the save function with the right fields filled in.

Reading means fetching rows out of the database. You might want all of them, or just the ones that match a condition.

Be clear about what you want back and in what order, so the AI writes a query that returns exactly the right rows.

Often you don't want every row, just the matching ones. Filtering uses conditions like "where status is open" or "where created after Monday."

State the filter plainly and the AI turns it into the proper query, whether that's SQL or an ORM call.

To change existing data, you update a row by finding it (usually by id) and setting new values.

Always tell the AI how to identify the right row, so the update touches only that record and not the whole table.

Deleting removes a row for good. It's powerful and easy to get wrong, so be precise about which row.

Many apps prefer a "soft delete," flipping an is_deleted flag instead of truly removing the data. Ask the AI which fits your case.

Data from users can be messy or even malicious. Inserting it directly into a query can cause errors or security holes like SQL injection.

Modern tools handle this with parameterized queries. Remind the AI to use safe, parameterized inserts rather than gluing strings together.

What happens when a read finds nothing? A search with no matches should show "no results," not crash.

Ask the AI to handle the empty case so your app behaves gracefully when the database returns zero rows.

As tables grow, reads can slow down. An index is like a book's index: it helps the database find rows quickly.

If a frequent query feels slow, ask the AI whether adding an index on the filtered column would help.

Before trusting your data layer, test it. Save a record, read it back, update it, then delete it, and confirm each step worked.

You can ask the AI to write these tests so future changes don't quietly break saving or reading.

With CRUD in place, your app finally remembers. Users create data, see it again, change it, and remove it, all backed by your database.

From here, every new feature is just another combination of saving and reading records.

Test your understanding of saving and reading records.

CRUD covers Create, Read, Update, and Delete: the four core data actions. You learned to save rows, read and filter them, update by id, and delete carefully, often with a soft delete.

Always use parameterized queries, handle empty results, index slow reads, and test your data layer. You can now add a working database to your AI app.