SQL Was Always Just Database Stuff to Me. Then I Started Writing Queries

I'd been meaning to learn SQL for quite some time.

It wasn't that I had no interest in databases. I knew they were an important part of software development, but SQL was one of those things I kept pushing further down my learning list.

Whenever I thought about it, I pictured tables, rows, columns, and something similar to working with Excel. I understood that databases stored information, but I hadn't really explored how developers interacted with that information.

Eventually, I decided to stop postponing it.

I opened Codecademy's Introduction to SQL course and spent about an hour and fifteen minutes working through the Manipulation module.

What surprised me wasn't that SQL suddenly became effortless. It was how quickly the basic concepts started making sense once I began writing the statements myself.

The commands were descriptive, the examples were practical, and I could see how each operation affected the information stored in a table.

Here's what stood out to me.

---

SQL Made More Sense When I Stopped Thinking About It Like Excel

One of the first things I had to understand was what a relational database actually represents.

A relational database organizes information into tables containing rows and columns.

That probably sounds familiar if you've used spreadsheets before. And honestly, that's where my earlier impression of SQL came from.

But there's more to it than arranging information in a grid.

In a relational database, tables have defined structures, data types, and rules that determine how information should be stored. SQL provides a way to interact with that information through statements.

Instead of manually finding and editing cells, you're describing an operation for the database to perform.

The course used a table called celebs, with columns such as id, name, and age.

Each row represented a record, while each column represented a particular attribute.

Once I understood that structure, the queries started feeling less abstract.

My First Query Was Surprisingly Straightforward

The first statement I worked with was:

SELECT * FROM celebs;

Just one line.

SELECT tells the database what information to retrieve, * represents all columns, and FROM celebs identifies the table.

In other words, I was asking the database to return all the information from that table.

If I only wanted the names, I could be more specific:

SELECT name FROM celebs;

This was where I began appreciating SQL's syntax.

Rather than memorizing a complicated sequence of operations, I could express what I wanted the database to return.

Of course, SQL is much more than a few readable keywords. But seeing a statement produce the expected result made the language easier to approach.

It also introduced an idea I found interesting: with SQL, you're often describing what result you want, rather than spelling out every individual step the database must take to produce it.

---

Creating a Table Helped Me Understand Its Structure

Retrieving information from an existing table was one thing. Creating the table myself helped connect the pieces.

One of the exercises involved writing:

CREATE TABLE celebs (
    id INTEGER,
    name TEXT,
    age INTEGER
);

This defines a new table with three columns.

The column names describe the information being stored, while the data types specify what kind of values the columns should contain.

For example, INTEGER represents whole numbers and TEXT represents text values.

I also learned that SQL keywords are commonly written in uppercase for readability, while a semicolon marks the end of a statement.

The syntax itself wasn't difficult to follow. What mattered was understanding why each part existed.

Once the table had been created, it was time to add records.

Adding Information with INSERT INTO

The next statement was INSERT INTO.

Here's a simplified version of the kind of example I practiced:

INSERT INTO celebs (id, name, age)
VALUES (1, 'Sample Artist', 29);

The statement identifies the table, specifies the columns receiving values, and provides the values to insert.

At this point, I could see how the operations connected.

CREATE TABLE establishes the structure, INSERT INTO adds records, and SELECT retrieves information from those records.

It sounds simple when explained that way, but actually writing and running the commands helped me understand the relationship between them.

---

ALTER TABLE and UPDATE Taught Me an Important Difference

Two commands I found particularly useful were ALTER TABLE and UPDATE.

They both change something, but they operate at different levels.

ALTER TABLE changes the structure of a table.

For example, the course introduced a new column called twitter_handle:

ALTER TABLE celebs
ADD COLUMN twitter_handle TEXT;

The table now had an additional column, but the existing records didn't automatically have values for it.

Those missing values were represented by NULL.

UPDATE, on the other hand, changes information already stored in the table.

For example:

UPDATE celebs
SET twitter_handle = '@example'
WHERE id = 1;

This changes the twitter_handle value for the record whose ID is 1.

The distinction became clear to me:

• ALTER TABLE modifies the table's definition.
• UPDATE modifies data within the table.

And then there's the WHERE clause.

It's easy to overlook, but it determines which records an operation affects.

Without the appropriate WHERE condition, an UPDATE statement could modify every row.

That was a useful reminder that readable syntax doesn't automatically make a command safe to execute.

You still need to understand exactly what you're asking the database to do.

DELETE FROM: A Simple Command with Serious Consequences

Another operation I practiced was deleting records.

The course used this query:

DELETE FROM celebs
WHERE twitter_handle IS NULL;

The statement removes records where twitter_handle has a NULL value.

I learned that NULL represents missing or unknown data. It isn't the same thing as zero or an empty string.

That's why SQL uses IS NULL to test for it.

Something else stood out here.

Compare the query above with:

DELETE FROM celebs;

Removing the condition changes the effect completely. Instead of deleting selected records, the statement would delete every row in the table.

That made me think more carefully about database operations.

The commands themselves might be straightforward, but understanding their consequences is just as important as knowing their syntax.

For more substantial databases, I'd want to inspect which records match a condition before running a destructive operation.

---

Constraints Showed Me How Databases Protect Their Data

Toward the end of the module, I learned about constraints.

Until then, I'd mostly been working with commands for creating, retrieving, and changing information.

Constraints introduced another responsibility: ensuring that the information stored in a table follows certain rules.

The course covered PRIMARY KEY, UNIQUE, NOT NULL, and DEFAULT.

One of the exercises involved creating an awards table:

CREATE TABLE awards (
    id INTEGER PRIMARY KEY,
    recipient TEXT NOT NULL,
    award_name TEXT DEFAULT 'Grammy'
);

There are a few important details here.

PRIMARY KEY identifies a record uniquely.

NOT NULL requires the recipient column to contain a value.

DEFAULT 'Grammy' supplies a predefined award name when a new record doesn't specify one.

I found this particularly interesting because it showed that managing a database isn't only about inserting and retrieving information.

It's also about controlling what information should be accepted in the first place.

As applications grow and more records are created, those rules become increasingly important.

---

What Actually Changed My Perspective

Looking back at the module, I think my biggest discovery was how much easier SQL became once I approached it as a language for communicating with a database.

Before starting, I mostly associated it with database tables and spreadsheet-style work.

After completing the introductory exercises, I could see a clearer process:

You define the structure of your data, insert records, retrieve what you need, make changes when necessary, and establish rules to maintain consistency.

Each command serves a purpose.

And because the statements are relatively descriptive, it didn't take long for the basic syntax to feel familiar.

That doesn't mean I've become proficient in SQL after one session.

I've only worked through the introductory Manipulation module. I still have plenty to learn about querying multiple tables, joins, aggregations, database relationships, and writing more advanced queries.

But I now understand the foundation well enough to see where those concepts fit.

I'm also beginning to appreciate why SQL remains relevant beyond people who work exclusively with databases. Applications depend on stored information, and understanding how to inspect and manage that information is valuable in software development, cloud engineering, and troubleshooting.

Final Thoughts

I spent roughly 75 minutes working through the eleven introductory exercises, and it changed how I viewed a subject I'd been putting off for a while.

SQL wasn't quite what I'd imagined.

The fundamentals were more approachable, the statements were readable, and experimenting with them helped me understand how information is managed inside a relational database.

The more interesting challenge now is taking those concepts beyond guided exercises.

I want to create a database locally, design my own tables, work with a more realistic dataset, and see how much of what I've learned I can apply independently.

That's when I'll have a better idea of how comfortable I really am with SQL.

For now, I'm glad I finally started.

Learning resource: Codecademy — Introduction to SQL

Sometimes a subject feels more complicated from a distance than it does when you actually sit down and work through the fundamentals.

Comments

[Odinaka Robert Nnamani]

That DELETE example without a WHERE clause does a lot of work in one line. It shows how readable syntax can still wipe a whole table if the condition is missing.

[Anderson Chinedum]

P.S. I'm planning to take SQL beyond the guided exercises and work with my own database next. For those who've been using SQL for a while, what would you recommend as a good first project?