To design your app's database, first list the things your app deals with, such as customers, appointments and services, and make each one a table. Then decide each table's columns, meaning the information you store about it, and the relations between tables: a customer has many appointments, an appointment includes many services. Finally set the rules: required fields, unique values, allowed statuses, and who can see which rows.
- how to design a database for my app
- database design for beginners
- what are relationships in a database
- database example for booking app
- difference between database and excel
- database without coding
How do you design a database for your app without being a developer?
To design a database for your app without coding experience, think in three layers, in order: tables, the things your app deals with such as customers, appointments and products; then the relations between them, such as a customer having many appointments; then the rules, such as a phone number never repeating and an appointment never being double-booked. If you can write those three layers in plain language, you have designed a database.
Why does this matter when you build with AI? Because the agent builds tables from your description. If the description is vague, it guesses, and it may guess wrong. Database mistakes are the hardest to fix later, because real data has piled up on top of them. Ten minutes of thinking at the start saves days of rework.
We will use one example throughout this guide: a booking app for a women's salon in Riyadh with services, staff, appointments and payments. If your data lives in Excel today, also read turn a spreadsheet into an app.
A beautiful app on a messy database is like an elegant shop with a storeroom where nothing can be found.
How is a database different from an Excel sheet?
A database resembles an Excel file with several sheets, but stricter and smarter. Each sheet is a table, each column has a defined type, each row has a unique id, and tables link to each other instead of copying information between them.
| Comparison | Excel sheet | App database |
|---|---|---|
| Data types | Anything in any cell | Each column has a type: text, number, date, yes or no |
| Duplication | The customer's name is copied into every order | The customer exists once and orders point to them |
| Rules | Nothing stops an empty cell or a duplicate number | Required fields and unique values are enforced automatically |
| Many users at once | Conflicts when editing at the same time | Hundreds of users at the same moment |
| Permissions | Whoever has the file sees everything | Each user sees only what is theirs |
| Querying | Manual filters | Precise, fast questions in SQL written by the app |
Step one: tables and columns
Write your app's story in two sentences and underline every important noun. In our example: A customer picks a service and a staff member, books an appointment, then pays. Those nouns are your first tables. Then ask of each table: what do I need to store about it?
| Table | Key columns | Note |
|---|---|---|
| Customers | id, name, phone, signup date | Phone is unique and required |
| Staff | id, name, status active or not | Do not delete someone who left; deactivate them |
| Services | id, Arabic name, English name, duration in minutes, price | Names in two languages in two columns |
| Appointments | id, customer, staff member, start time, end time, status | Customer and staff point to their tables |
| Appointment services | appointment, service, price at booking | A join table, explained shortly |
| Payments | id, appointment, amount, currency, method, status, gateway transaction id | One or more payments per appointment |
Step two: relations between tables
A relation answers: how many of this connect to how many of that? There are only three kinds, and understanding them solves most design questions.
- 1One-to-many
One customer has many appointments, and each appointment belongs to one customer. The fix: a customer id column inside the appointments table. This is the most common kind.
- 2Many-to-many
An appointment can include many services, and a service appears in many appointments. The fix: a join table, appointment services, where each row links one appointment to one service.
- 3One-to-one
Rare: for example a settings record per staff member. Usually putting the columns in the same table is enough.
Another example from the same app: a staff member offers many services, and a service is offered by many staff. That is many-to-many and needs a join table, say staff services, defining who can do what. Without it, the app will offer a customer a stylist who does not provide the service she wants.
Step three: rules that protect your data
Database rules are your last line of defense. Even if a screen has a bug or someone tries to tamper with requests, the database rejects bad data.
- Required fields: no appointment without a customer and a start time.
- Unique values: a phone number never repeats across customers.
- Fixed statuses: an appointment's status comes from a fixed list: booked, confirmed, completed, cancelled, no-show. No free text.
- Sensible ranges: prices are never negative, and the end time is after the start time.
- No conflicts: no two appointments for the same staff member at overlapping times. This is a business rule you must state explicitly to the agent.
- What happens on delete: if a service is deleted, does it vanish from past appointments? Deactivating instead of deleting is usually better.
Who sees which row?
Permissions are part of the design, not an afterthought. Customers see only their own appointments, staff see today's schedule for themselves, and the manager sees everything. Write one clear sentence per role. For details, read roles and permissions for staff.
Gulf details that change the design
- Money as integers with a currency: store 15000 halalas with SAR instead of 150.00, and remember the Kuwaiti and Bahraini dinars use three decimals.
- Prices as a frozen copy: store the service price inside appointment services at booking time. If you raise prices later, old appointments and invoices do not change.
- Time in one standard zone: store times in UTC and display them in Riyadh or Dubai time. Do not store the Hijri date as a separate column; calculate it for display from the Gregorian date.
- Two languages, two columns: service names in Arabic and English in separate columns, not machine-translated on display.
- Phone in international format: always store numbers with the country code so search and messaging work.
- Audit fields: created at, updated at and created by on every important table. You will need them in any dispute.
These details connect to other systems: invoices and VAT, the Hijri calendar and personal data. For appointment apps specifically, see building a salon booking app in Saudi Arabia.
Common mistakes and a ready build prompt
- One huge table holding everything
- Comma-separated lists inside a cell
- Status as free text anyone can type
- Hard-deleting old records
- Totals stored without the details behind them
- A table per independent thing, with an id
- Join tables for many-to-many relations
- Statuses from a fixed list
- Archive or deactivate instead of deleting
- Details stored, totals calculated from them
Design a database for a women's salon booking app in Riyadh, and show me the design as tables and relations in plain language before building. Tables: customers (name, phone in international format and unique), staff (name, active or deactivated), services (Arabic and English names, duration in minutes, price in halalas), staff services as a join table, appointments (customer, staff member, start, end, status from a list: booked, confirmed, completed, cancelled, no-show), appointment services as a join table with the price at booking, payments (amount in halalas, currency, method, status, transaction id). Rules: no overlapping appointments for the same staff member, end after start, services are deactivated rather than deleted. Times stored in UTC and shown in Riyadh time with the Hijri date. Permissions: customers see their appointments, staff see their schedule, the manager sees everything. Add created and updated fields to every table.
Try it in FanannOnce built, your database is the most valuable thing in your app, so set up backups and disaster recovery. For more phrasing ideas, see prompts for database design. In Fanann the managed database comes with daily backups and full code export.
Key takeaways
- Every important thing in your app is a noun: customer, order, product. Each noun is a table, and each detail about it is a column.
- Relations are the heart of the design: one-to-many through an id, many-to-many through a join table.
- Database rules protect you from bad data whatever its source: required fields, unique values and fixed statuses.
- Store money as integers with a currency, times in one standard time zone, and prices at order time as a frozen copy.
- Write the design in words before building and ask the agent to show it to you; changing a plan is far cheaper than changing a live app.
Frequently asked questions
How do I design a database for my app if I am not a developer?
What are relationships in a database?
What is the difference between a database and Excel?
Can I change the database after launching my app?
Do I need to learn SQL to build an app?
Ask your AI assistant about this
Copy this prompt into the AI assistant you use, then add the details of your own case.
I am reading this guide: “Database design for non-developers: tables, relations and rules” https://fanann.com/en/blog/design-database-for-app/ My question: how to design a database for my app Use that page as a source and explain the answer step by step for my situation, tell me what to check before I start, and cite the page link.