The Day My Database Became the Problem.

The first database is usually too simple.

Beginners often think about database tables individually.

A users table. A products table. An orders table.

The more important question is how those tables relate to each other.

Users
  ↓
Orders
  ↓
Order Items
  ↓
Products

Once this relationship is clear, many backend decisions become easier.

A table should have a reason to exist.

One useful way to think about a relational table is that it represents one type of thing or one meaningful relationship.

For example, a products table might contain:

products
──────────────
id
name
description
price
image
stock
category_id

The important part is not memorizing columns. It is understanding what each column represents and who owns that information.

If a value describes a product, it belongs with the product. If it describes an order, it belongs with the order. If it describes the relationship between an order and a product, it may belong in an order-items table.

Relationships are where the real design begins.

Consider an e-commerce application.

One user can create many orders. One order can contain many products. One product can appear in many orders.

That creates a relationship structure.

Instead of storing a giant product list directly inside every order row, a relational model can represent the relationship using an order-items table.

order_items
──────────────
id
order_id
product_id
quantity
price

This structure gives the backend a much clearer representation of what actually happened during a purchase.

The API is the bridge between the UI and the database.

The browser normally should not communicate directly with the database.

Instead, the backend receives a request, validates it, performs the required database operation and returns a response.

React
  ↓
POST /api/orders
  ↓
Express
  ↓
Validation
  ↓
SQL Query
  ↓
MySQL
  ↓
Result
  ↓
JSON Response
  ↓
React

Once this flow is clear, database problems can be isolated much more quickly.

If the API receives incorrect data, investigate the frontend. If the API receives correct data but stores it incorrectly, investigate the backend or SQL query.

SQL is where your application asks questions.

A database becomes useful when the application can retrieve exactly the information it needs.

SELECT
  id,
  name,
  price
FROM products
WHERE stock > 0
ORDER BY price ASC;

The query expresses a very specific question: give me products that are available and order them by price.

As applications grow, queries become more complex. Joins, filtering, sorting and aggregation can all affect how efficiently the database answers those questions.

SELECT
  orders.id,
  users.name,
  orders.total
FROM orders
JOIN users
  ON orders.user_id = users.id;

Understanding SQL therefore becomes more important as the backend becomes more sophisticated.

Sometimes the problem is not the query. It is how the database searches.

Databases may need to inspect many rows to find the information requested by a query.

Indexes can provide a more efficient way to locate frequently searched values.

But indexes are not free.

They consume storage and can add work when data is inserted or updated. The right approach is therefore not “index everything.” It is to understand the queries the application actually runs.

The database mistakes that hurt later.

Design the data before designing every screen.

One of the biggest lessons I learned is that frontend decisions become easier when the underlying data model is clear.

If you know what a product is, what an order is and how they relate, the API becomes easier to design.

If the API is clear, the React state becomes easier to structure.

Good database design therefore affects much more than SQL.

What data exists?
       ↓
Who owns it?
       ↓
How is it related?
       ↓
Which API exposes it?
       ↓
How does the UI consume it?

A good database makes the rest of the application quieter.

When the data model makes sense, the backend has fewer awkward decisions to make.

When the backend is predictable, the frontend becomes easier to build.

When the frontend receives predictable data, the user gets a more reliable experience.

That is why database design is not just a backend concern. It is part of the architecture of the entire product.