Database and SQL Basics: How Apps Store and Ask for Data

by Souy Soeng /October 14, 2026

Diagram of a users table with rows and columns next to a simple SQL SELECT query asking for names and emails

Database and SQL basics come down to two ideas: a database keeps data organized in tables of rows and columns, and SQL is the language used to ask that database questions. Every app you use, from your messages to your orders to your bank balance, stores information this way and asks for it this way.

This guide follows the same path as the video. It starts with why databases exist, then walks through real SQL commands one small step at a time: creating a table, adding data, reading it back, filtering, sorting and changing it. It ends with the mistakes that wipe data and the habits that prevent them. Tables, SQL, queries and safety are the four ideas that cover the whole map.

In short

A database stores data in tables: one table per kind of thing, one row per record, one column per detail.
SQL (Structured Query Language) is the standard language for asking relational databases questions.
CREATE TABLE defines the shape, INSERT adds rows, and SELECT … FROM reads them back.
WHERE picks which rows you mean, and ORDER BY sorts them. Leave WHERE off an UPDATE or DELETE and every row changes.
Primary keys, testing with SELECT first, regular backups and transactions keep your data safe.

When does a spreadsheet stop coping?

Picture a small online shop that keeps every customer and every order in one shared spreadsheet. At first it works fine. As the data grows and more people touch it, it quietly starts to break. Files end up with names like orders_final_v3, two people edit the same cell, and the sheet slows to a crawl as the rows pile up.

Two problems do the most damage. The first is lost updates. When two people save at the same time, one person's change can silently overwrite the other's. Nobody sees an error, and the mistake may only surface when a customer complains about a missing order. The second is that there is no single source of truth. Copies get emailed around, and soon nobody knows which version is current.

Most growing teams run into this sooner or later. You may have felt a small version of it yourself when fighting over a shared file with friends or coworkers. Databases were built to solve exactly this problem.

Lost updates: two saves at once, and one change disappears
No single truth: emailed copies make it unclear which file is current
Large sheets slow down as rows pile up

What is a database, and how is it different from a file?

A database is an organized collection of data, usually stored in tables made of rows and columns. If you can read a spreadsheet, you already understand its basic shape. The key word is organized: everything has its own place, so a computer can find it quickly instead of digging through a messy pile of files each time you ask.

Each table holds one kind of thing, such as users, orders or products, which keeps every table small and easy to understand. A row is one record. In a users table, one row is one person, say Maya, with her email and the day she signed up. A column is a detail every row shares, like name, email or signup date. Each column also has a type, so a date column only accepts dates.

To be fair to spreadsheets, they are excellent for personal lists and quick analysis. Trouble starts when an app needs the same data all day, for many people at once. A database handles very large data, lets many users and programs work at the same time without stepping on each other's changes, enforces rules that keep data clean, and answers precise questions. When data matters to many people at once, it belongs in a database.

Tables: one per kind of thing (users, orders, products)
Rows: one record, like one customer
Columns: one detail, like name, email or date

What is SQL, and how do you pronounce it?

SQL stands for Structured Query Language. It is the standard language for relational databases. Relational simply means the data lives in tables that can be linked to each other. Some people say "S-Q-L" and others say "sequel", and both are perfectly fine.

SQL reads almost like plain English. In the example below, SELECT name, email picks the columns you want, and FROM users says which table to look in. This style is called declarative: you describe what you want, not how to fetch it, and the database works out the fastest way to find the answer.

SQL is also portable. MySQL, PostgreSQL, SQLite and SQL Server all speak it. Each has small dialect differences, but the basics in this guide carry over to all of them, so you only need to learn the core once.

# Ask the database a clear question
SELECT name, email
FROM users;

How does an app talk to a database?

Beginners often miss this detail: your phone never talks to the database directly. When you tap a button in an app, a chain of parts passes your request along until a SQL query reaches the database.

Take a login. Your phone sends the login tap to the app server. The server checks who you are, turns that tap into a SQL query, and sends it to the database. The database looks in the users table, finds the matching row, and sends the result back along the same chain.

So it is code on the server that writes the SQL, for example a query that selects from users where the email matches yours. That is why backend developers use SQL every day, even though users never see it. Every app with accounts works this way.

How to create a table in SQL

Before you can store anything, you create a table and define its columns. Think of it as drawing an empty grid and labelling each column. Getting the shape right makes everything after it easier, because every row you add later must fit that exact shape.

Read the example line by line. CREATE TABLE users starts the table. id INT PRIMARY KEY gives every row a unique number. name and email are text columns, and the signup date is a date column. The closing bracket finishes the definition.

Column types such as TEXT, INT and DATE tell the database what each column may hold. Try to put the word "hello" into the date column and the database simply refuses it. The primary key works like a student number: a unique label for each row, so two people who are both called Maya never get mixed up.

Column types: each column accepts one kind of value
Primary key: a unique id for every row

CREATE TABLE users (
  id INT PRIMARY KEY,
  name TEXT,
  email TEXT,
  signup_date DATE
);

Adding and reading data with INSERT and SELECT

A new table is empty. INSERT adds rows, and SELECT with FROM reads them back. These two commands are the heart of everyday SQL, and almost every app action boils down to one of them. Signing up is an insert. Opening your profile is a select. Once you see this pattern, apps start to look much less mysterious.

In the example, INSERT INTO users with the values 1, Maya, her email and her signup date adds one new row. Then SELECT name, email FROM users reads it back, and Maya appears in the results.

Watch your quotes. Words and dates go inside single quotes, while numbers like the id don't. A missing quote is one of the most common first errors, so check it first. Also note that SELECT * ("select star") means every column. It is handy while exploring, but in real apps it is better to name the columns you need, because * fetches more than you asked for.

# add one row
INSERT INTO users VALUES
  (1, 'Maya', 'maya@mail.com', '2024-03-01');
# read it back
SELECT name, email FROM users;

Using WHERE to filter, sort, update and delete

Real tables can hold thousands of rows, so you need sharper questions. WHERE works like a sieve that keeps only matching rows, and ORDER BY lines them up. In the worked example, FROM users starts with 5 rows. A WHERE filter keeps people who signed up in 2024 or later, leaving 3. ORDER BY in descending order puts the newest first, and SELECT name returns Leo, Maya and Sam. Write the clauses in this order: SELECT, FROM, WHERE, ORDER BY. Mixing them up causes a syntax error.

The same WHERE clause decides which rows change. UPDATE edits existing rows and DELETE removes them. For example, UPDATE users with SET email and WHERE id = 1 changes only Maya's address. Exactly one row is updated and everyone else is untouched. If you leave WHERE out, every row changes.

A database does exactly what you ask, instantly, with no "are you sure?" box. Two habits help. First, run the same WHERE with SELECT, and if it shows the rows you expect, swap in UPDATE or DELETE. Second, target rows by primary key. Matching on the name Maya might hit three different people, but matching on id 1 hits exactly one.

WHERE keeps matching rows; ORDER BY sorts them
Order of clauses: SELECT, FROM, WHERE, ORDER BY
Preview with SELECT before UPDATE or DELETE
Match on the id, not on a name

Where are databases used in real life?

Behind almost every app with accounts sits a database. Banks keep balances and every transfer. Online stores track products and orders. Social media stores posts and likes. Logins on almost every website check user accounts. Scrolling a feed is mostly reads, while posting, liking or paying are writes, and busy apps do both constantly. This is about trust, too: your balance is only as reliable as the database recording it.

Here is one online order from start to finish. You click buy on a pair of headphones. The store server first SELECTs from the products table to check they are in stock, then UPDATEs the stock count. Next it INSERTs a new row into the orders table with your user id, the product and today's date. Finally it reads that order back with a SELECT to show your order page and send the confirmation email.

None of these steps is new. It is the same handful of commands you have already seen, chained together in the right order. A few basics go a very long way.

Common SQL mistakes and how to protect your data

Most beginner disasters come from a few small, very common slips, and experienced developers have made every one of them. The classic is forgetting WHERE. A DELETE FROM users with no WHERE empties the whole table, and an UPDATE without it changes every row. Write the WHERE line first and test it with SELECT. The second mistake is having no primary key, which leads to duplicate rows that look identical and no safe way to change just one. Give every table a unique id from day one.

Professionals also plan for mistakes, because they will happen. Think of these habits as a seatbelt: boring until the day you need it. The goal is not to be perfect but to make any mistake quick and calm to undo.

Take regular backups on a schedule, store them somewhere else, and practise restoring them, because an untested backup might not work. Try risky changes on a practice copy first, never on the live database customers depend on. Use transactions to group changes so they all succeed or none do. In the shop example, the stock update and the new order are saved together, never left half-finished.

Forgot WHERE: UPDATE or DELETE hits every row
No primary key: duplicates and no safe way to target one row
Regular, tested backups
Test on a copy before touching live data
Transactions: all changes succeed, or none do

Key takeaways

Databases store data in tables of rows and columns, and each column has a type.
Spreadsheets struggle with large, shared, constantly changing data. Databases are built for it.
SQL is how we talk to databases: CREATE a table, INSERT rows, then SELECT … FROM to read them.
Filter with WHERE and sort with ORDER BY, written in the order SELECT, FROM, WHERE, ORDER BY.
Always use WHERE on UPDATE and DELETE, and target rows by primary key.
Backups, practice copies and transactions turn mistakes into minor events.

Frequently asked questions

Is SQL pronounced "S-Q-L" or "sequel"?

Both are fine and widely used. SQL stands for Structured Query Language, and people pronounce it either way.

What is the difference between a database and a spreadsheet?

Both organize data into rows and columns, but a database is designed for large data that many people and programs use at the same time. It enforces rules such as column types and avoids problems like lost updates and conflicting copies. Spreadsheets remain great for small personal lists and quick analysis.

Does learning SQL work for MySQL, PostgreSQL and SQLite?

Yes. MySQL, PostgreSQL, SQLite and SQL Server all speak SQL. Each has small dialect differences, but basics like SELECT, INSERT, WHERE and ORDER BY carry over to all of them.

What happens if you run DELETE without WHERE?

Every row in the table is deleted, with no warning or confirmation. Without a backup, that data is gone for good. Write the WHERE clause first and test it with a SELECT before running the DELETE.

Why does every table need a primary key?

A primary key gives each row a unique id, like a student number. Without one, you can end up with identical duplicate rows and no safe way to update or delete just one of them.

What does a database transaction do?

A transaction groups several changes so they either all succeed or none do. For example, an online store saves the stock update and the new order together, so neither is left half-finished.

Watch the full video on YouTube →

Tag

Ad