Querying & Filtering in Oracle Databases: What Actually Clicked for Me As a Beginner

Source: Dev.to

Today’s Quiet but Important SQL Day

No new tables. No fancy joins. Just learning how to ask better questions of the data I already have.

The lesson was all about querying and filtering rows—basically learning how to tell the database exactly what I want back, and nothing more.

I learned this through a simple toys table, which honestly helped a lot. Oracle courses teach in a weird but funny manner that lets you learn and have fun while you do it. They make very daunting topics look less intimidating by approaching them with easy‑to‑understand, relatable concepts.

create table toys (
  toy_name varchar2(100),
  colour   varchar2(10),
  price    number(10,2)
);

insert into toys values ( 'Sir Stripypants',   'red',   0.01 );
insert into toys values ( 'Miss Smelly_bottom','blue',  6.00 );
insert into toys values ( 'Cuteasaurus',       'blue', 17.22 );
insert into toys values ( 'Mr Bunnykins',      'red',  14.22 );
insert into toys values ( 'Baby Turtle',       'green', null );

commit;

Selecting Rows (and Why SELECT * Is a Trap)

The very first thing was learning that SELECT really has two jobs:

• FROM → where the data lives
• SELECT → what columns I actually want back

At first, SELECT * FROM toys; is very convenient, but only when your database is small. Imagine a bigger database with over 10 000 rows—SELECT * isn’t going to help you find Mr Bunnykins in there.

select toy_name, price
from toys;

This forces you to think about what you actually need, and it also:

• Sends less data over the network
• Breaks less when columns change

That alone already changed how I write queries. Be specific and effective.

Filtering Rows with WHERE

Instead of getting everything in the table, you can start asking questions like:

“Only show me the red toys”

select *
from toys
where colour = 'red';

“Give me just one specific row”

select *
from toys
where toy_name = 'Sir Stripypants';

Simple, but this is the foundation of almost every real query.

Combining Conditions: AND, OR, and Confusion

This part tripped me up more than I expected.

where toy_name = 'Mr Bunnykins'
or  toy_name = 'Baby Turtle'
and colour = 'green';

The results weren’t what I expected because AND runs before OR. SQL doesn’t read conditions left‑to‑right the way our brains do.

The fix? Use parentheses—always.

where (toy_name = 'Mr Bunnykins' or toy_name = 'Baby Turtle')
  and colour = 'green';

Now the query does exactly what it looks like it should do. This alone has saved me from future bugs.

Lists of Values with IN

Instead of writing:

where colour = 'red'
   or colour = 'green'
   or colour = 'blue'
   or colour = 'yellow';

You can write:

where colour in ( 'red', 'green', 'blue', 'yellow' );

Much cleaner, easier to read, and far more effective—especially when you need just a handful of rows out of 100 000+.

Ranges with =, and BETWEEN

where price between 6 and 20;

Important detail: BETWEEN includes both ends. If you want strict boundaries, write them yourself:

where price > 6
  and price `:

where colour <> 'green';

But again—NULL is special. To exclude nulls, you must use:

where colour is not null;

There’s no shortcut here.

Final Thoughts

This lesson didn’t feel flashy, but it felt important. Everything else in SQL builds on this:

• Aggregations
• Joins
• Subqueries
• Real‑world analytics

If you can’t filter data confidently, everything else falls apart.

Feels Fragile

I’m learning to slow down, be explicit, and write queries that are readable and effective.

If you’re also learning SQL and sometimes feel silly getting tripped up by WHERE clauses… you’re not alone.

I’ll keep documenting this journey—the confusion, clarity, and all.