Introduction
When I first heard the terms DDL and DML thrown around in class, I honestly thought they were just more database jargon I would have to memorize. But after this week's assignment, I actually get why that distinction matters — it's the difference between building a database and talking to it. Here's what I learned, what I struggled with, and why SQL is starting to feel less like a foreign language.
DDL vs DML — What's the Difference?
DDL stands for Data Definition Language. It's the set of SQL commands you use to define, create, and modify the structure of your database — the tables, columns, data types, and constraints. Think of DDL as the blueprint phase: you're not touching any actual data yet, you're just setting up the rooms.
DML stands for Data Manipulation Language. Once the structure is in place, DML is how you work with the data inside it — inserting records, updating values, deleting rows, and querying results.
A simple way to remember it:
DDL - Defines the structure CREATE, ALTER, DROP
DML - Manipulates the data INSERT, UPDATE, DELETE, SELECT
How I Used CREATE, INSERT, UPDATE, and DELETE
CREATE — Building the Table
The first thing I did was create a table to store student records. The CREATE TABLE statement lets you define column names, their data types, and any rules they must follow:
CREATE TABLE students (
student_id INT PRIMARY KEY,
first_name VARCHAR(50) NOT NULL,
last_name VARCHAR(50) NOT NULL,
gender VARCHAR(1),
date_of_birth DATE,
class VARCHAR(10),
city VARCHAR(50) );
);
INSERT — Populating the Table
With the table ready, I used INSERT INTO to add records:
INSERT INTO students (student_id, first_name, last_name, gender, date_of_birth , class, city)
VALUES
('1','Amina', 'Wanjiku', 'F', '2008-03-12', 'Form 3', 'Nairobi'),
('2','Brian', 'Ochieng', 'M', '2007-07-25', 'Form 4', 'Mombasa'),
('3','Cynthia', 'Mutua', 'F', '2008-11-05', 'Form 3', 'Kisumu'),
Column order in the VALUES clause must match the column order you listed — one mismatch and the data lands in the wrong place.
UPDATE — Changing Existing Records
UPDATE lets you modify data that's already in the table. This is where the WHERE clause becomes non-negotiable — without it, you update every single row:
UPDATE students
SET city = 'Nairobi'
WHERE student_id = 5;
DELETE — Removing Records
DELETE removes rows from a table. Again, WHERE is your best friend here:
DELETE from exam_results
WHERE result_id = 9;
Without a condition, DELETE FROM students wipes the entire table clean. The structure stays — but every record disappears.
Filtering with WHERE — Getting Specific
The WHERE clause is how you narrow down which rows a query affects or returns. SQL gives you a rich set of operators to work with:
Equality and comparison:
SELECT * FROM students WHERE age = 20;
SELECT * FROM students WHERE age > 18;
SELECT * FROM students WHERE age <= 21;
BETWEEN — for ranges:
SELECT * FROM students
WHERE age BETWEEN 18 AND 22;
This is inclusive on both ends, which tripped me up initially.
IN — for matching a list of values:
SELECT * FROM students
WHERE grade IN ('A', 'B');
Much cleaner than writing grade = 'A' OR grade = 'B'.
LIKE — for pattern matching:
SELECT * FROM students
WHERE full_name LIKE 'A%';
The % is a wildcard that means "anything can follow here." So this returns all students whose names start with the letter A. You can also use %a% to find names containing a specific letter anywhere.
CASE WHEN — Transforming Data on the Fly
CASE WHEN is SQL's version of an if-else statement. Instead of storing a new column, you can create a derived one right inside your query:
SELECT
full_name,
grade,
CASE
WHEN grade = 'A' THEN 'Distinction'
WHEN grade = 'B' THEN 'Credit'
WHEN grade = 'C' THEN 'Pass'
ELSE 'Needs Improvement'
END AS performance_label
FROM students;
This doesn't change any data in the table — it just adds a readable label in the results. I used something similar to categorize students into age groups (Teen, Young Adult, Adult) without needing a separate column for it. It made my query results much easier to read and share.
Reflection — What I Found Challenging and Interesting
The hardest part was building good habits around WHERE. It sounds simple, but the consequences of forgetting it — especially with UPDATE and DELETE — are immediate and very visible.
The most interesting part was CASE WHEN. It felt like the moment SQL stopped being just a data fetching tool and started feeling like a programming language. The idea that I can transform how data looks without touching the actual table is genuinely useful — especially for reporting and presentations.
What surprised me most was how much clarity the DDL vs DML distinction adds. Knowing which phase of database work I'm in helps me think more carefully about what I'm doing — am I building or am I querying?.
Wrapping Up
SQL is starting to feel less like memorizing commands and more like learning a way of thinking about data — defining it, shaping it, and asking it questions. CREATE and INSERT build the world. UPDATE and DELETE maintain it. WHERE focuses your intent. And CASE WHEN lets you see data in new ways without ever touching what's underneath.
Top comments (0)