Databases for People Who Live in Spreadsheets

If you've ever kept a spreadsheet of anything (customers, books you've read, expenses), you already understand most of what a database is. You've got rows, you've got columns, every row is one thing and every column is one fact about it. A relational database is that idea, made strict and fast and able to handle millions of rows without your laptop fan taking off.

The strict part is the important difference. A spreadsheet lets you type "twelve" into a column that's supposed to hold numbers, leave half the cells blank, and spell the same customer's name three different ways. A database makes you decide up front what each column holds, and then it enforces it. Annoying for about a day. After that you realize it's the reason your data stays trustworthy.

The other big difference is that databases are built to be used by programs, not just people. When you log into a website, check your order history, or search a store, there's almost certainly a database behind it answering questions. MySQL, MariaDB, PostgreSQL and SQLite are the common ones you'll hear about. They differ in the details, but they all speak the same basic language: SQL.

SQL (people say "sequel" or spell it out, both are fine) is how you talk to the database. It reads more like English than most code, which makes it a nice first language even if you never write anything else. Here's a table for a small book log:

CREATE TABLE books (
    id INTEGER PRIMARY KEY,
    title TEXT NOT NULL,
    author TEXT NOT NULL,
    year_read INTEGER,
    rating INTEGER
);

Every table should have a primary key, a column that uniquely identifies each row. Here it's id, and the database fills it in for you. NOT NULL means the column can't be left empty. That's the strictness at work.

Adding data:

INSERT INTO books (title, author, year_read, rating)
VALUES ('The Hobbit', 'J.R.R. Tolkien', 2024, 5);

Getting it back out is where SQL starts to feel useful. You describe what you want, and the database figures out how to find it:

SELECT title, rating
FROM books
WHERE rating >= 4
ORDER BY title;

That's "show me the title and rating of every book I rated 4 or higher, alphabetically." You can count and group too:

SELECT author, COUNT(*) AS books_read
FROM books
GROUP BY author
ORDER BY books_read DESC;

Changing and removing rows looks like this:

UPDATE books SET rating = 4 WHERE id = 1;

DELETE FROM books WHERE id = 1;

Please notice the WHERE on both of those. Leave it off an UPDATE and you change every row in the table. Leave it off a DELETE and you empty the table. This is the classic beginner mistake and plenty of experienced people have done it too. A good habit: write the SELECT with your WHERE first, check it returns exactly the rows you expect, then swap it for the UPDATE or DELETE.

The "relational" part is where databases really pull ahead of spreadsheets. Instead of typing the author's name into every book row, you'd keep authors in their own table and have each book point to one by its id. Then you combine them when you ask a question:

SELECT books.title, authors.name
FROM books
JOIN authors ON books.author_id = authors.id;

Now if you fix a typo in an author's name, you fix it in one place and every book picks it up. That idea, storing each fact once and linking to it, is most of what database design is about.

If you're writing an app that talks to a database, one rule is non-negotiable: never build SQL by gluing user input into a string. Use prepared statements (sometimes called parameterized queries), where the query and the data are sent separately. In PHP with PDO that looks like:

$stmt = $pdo->prepare('SELECT * FROM books WHERE author = ?');
$stmt->execute([$author]);

This is how you stop SQL injection, which is still one of the most common ways websites get broken into. Every language has an equivalent, and there's no good reason to skip it.

You'll also hear about "NoSQL" databases that store documents or key-value pairs instead of tables. They have real uses. But for most projects, especially your first ones, a regular relational database is the right call and will take you a very long way.

If you want to play with this today, SQLite is the easiest place to start. It's a whole database in a single file, there's no server to set up, and there are free desktop apps like DB Browser for SQLite that let you click around and run queries. Make a table of something you actually care about and start asking it questions. It clicks fast.