Databases in Plain English: Tables, Documents, and Queries

Why apps need a memory

If a page only keeps information in a variable, that information usually disappears when the page closes. A database is a place an app can save information so it is still there later. It can store accounts, messages, orders, settings, or project inquiries.

Think of it like a well-organized filing room. The app writes down a record, gives it a way to find it later, and asks the database for the records it needs.

Tables and SQL

In a relational database such as PostgreSQL, information is arranged in tables. A table is like a spreadsheet: each row is one thing, and each column describes one detail. A projects table might have an ID, a name, and a status.

CREATE TABLE projects (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  status TEXT NOT NULL
);

INSERT INTO projects (name, status)
VALUES ('Portfolio redesign', 'in progress');

SELECT name, status
FROM projects
WHERE status = 'in progress';

SQL is the language used to describe many actions on relational databases. SELECT asks for information; INSERT adds a row. A primary key is a unique label for each row, like a library book’s catalog number.

Tables can connect through these IDs. For example, each order can point to the ID of the customer who made it. That way, the database can connect related information without copying every customer detail into every order.

Documents and MongoDB

MongoDB stores information as documents that look a little like JSON. A project could be saved as one bundle of named values:

{
  "name": "Portfolio redesign",
  "status": "in progress",
  "tags": ["web", "design"]
}

This shape can be handy when records naturally have different details or nested lists. Relational tables are often a good fit when information has clear relationships and you need those relationships to stay consistent. Document databases can be convenient when records vary more.

Neither kind wins every time. The useful question is: what information does the app need to save, how does that information relate, and what questions will the app ask most often?

Choose carefully and protect the data

A database is not just a box to put things in. You need rules for who can read or change each record, and you need a plan for backups. For example, a visitor might be allowed to submit a project inquiry but should not be allowed to read everyone else’s inquiries.

Start by drawing the information your app needs on paper. Give each kind of thing its own table or document, decide how they connect, and write down who is allowed to access them. That small plan can prevent a lot of confusing code later.