# How Childhood Exam Bribery Taught You AND, OR, and the Parentheses Scam

Every kid on earth grew up on a steady diet of conditional promises.

Before every Friday pop quiz, mid-term assessment, or final report card, parents rolled out elaborate reward systems. It always sounded like a fair, bilateral negotiation. You wanted a brand-new bicycle, a next-gen gaming console, and a pizza party. Your parents nodded thoughtfully, took a sip of coffee, and agreed to the "*terms*."

Only when the report card arrived with an '**A**' grade did you discover the harsh reality: you were outsmarted by SQL Boolean logic and operator precedence.

Let's dissect how relational databases process compound conditions using the oldest filter engine known to humankind: **parental bribery**.

**The Database Schema: The Household Ledger**  
Before making promises, parents maintain an internal catalog of potential rewards, their baseline cost, and the minimum academic score required to unlock them.

Here is the table structure behind every living room negotiation:

```plaintext
CREATE TABLE childhood_rewards (
    reward_id INT PRIMARY KEY,
    item_name VARCHAR(50),
    category VARCHAR(30),
    min_grade_percent INT,
    estimated_cost INT
);

INSERT INTO childhood_rewards VALUES
(1, 'Snack Pack with Cheap Toy', 'Snack', 75, 5),
(2, 'Extra 30 Mins Screen Time', 'Entertainment', 80, 0),
(3, 'Insulated Water Bottle', 'Utility', 85, 20),
(4, 'Mountain Bike', 'Luxury', 90, 250),
(5, 'Gaming Console', 'Luxury', 95, 500),
(6, 'Brown Book Cover Roll', 'Necessity', 0, 5);
```

```plaintext
+-----------+---------------------------+---------------+-------------------+----------------+
| reward_id | item_name                 | category      | min_grade_percent | estimated_cost |
+-----------+---------------------------+---------------+-------------------+----------------+
| 1         | Snack Pack with Cheap Toy | Snack         | 75                | 5              |
| 2         | Extra 30 Mins Screen Time | Entertainment | 80                | 0              |
| 3         | Insulated Water Bottle    | Utility       | 85                | 20             |
| 4         | Mountain Bike             | Luxury        | 90                | 250            |
| 5         | Gaming Console            | Luxury        | 95                | 500            |
| 6         | Brown Book Cover Roll     | Necessity     | 0                 | 5              |
+-----------+---------------------------+---------------+-------------------+-------------
```

![](https://cdn.hashnode.com/uploads/covers/6a985257c384f37738abcc7f/3bdb3b5c-a142-4b55-911c-008c28f3b0c7.png align="center")

**Act 1:** **The Friday Quiz** **— The Lenient** `OR`

For low-stakes Friday quizzes, parental budgets are relaxed. Because the consequences are minor, they implement an `OR`condition.

In Boolean logic, an `OR`operator returns `TRUE`as long as at least one condition is satisfied. It only evaluates to `FALSE`if every single condition fails.

**The Parental Contract:**

> "Score an 80% or higher, and you can pick a snack pack OR an extra 30 minutes of cartoons."

```plaintext
SELECT item_name, estimated_cost
FROM childhood_rewards
WHERE item_name = 'Snack Pack with Cheap Toy' 
   OR item_name = 'Extra 30 Mins Screen Time';
```

**What the Database Evaluates:**

```plaintext
+---------------------------+----------------+
| item_name                 | estimated_cost |
+---------------------------+----------------+
| Snack Pack with Cheap Toy | 5              |
| Extra 30 Mins Screen Time | 0              |
+---------------------------+----------------+
2 rows returned.
```

Because both rows exist in the table, both are valid options. You pick the snack pack, get a plastic whistle that breaks in five minutes, and spend the evening watching cartoons. The system feels generous.

**Act 2: The Mid-Term Demands — The Strict** `AND`  
Flush with confidence from your Friday victory, you step up your demands for mid-terms. You approach your parents with a wishlist, using what you assume is regular conversational "`AND`" (which humans use for addition).

In SQL, however, `AND` is not an addition sign. It is a strict gatekeeper. Every single condition chained by an `AND` must evaluate to `TRUE` simultaneously on the same row.

> The Wishlist Query:  
> "I want a bike AND a gaming console AND a new water bottle!"

```plaintext
SELECT item_name
FROM childhood_rewards
WHERE item_name = 'Mountain Bike'
  AND item_name = 'Gaming Console'
  AND item_name = 'Insulated Water Bottle';
```

**What the Database Returns:**

```plaintext
Empty set (0.00 sec)
```

Why Did You Get Nothing? A single row in a database cannot have its `item_name` column equal to `'Mountain Bike'` and `'Gaming Console'` at the exact same millisecond.

Beginner developers make this error constantly: they treat `AND` as "*fetch me this item, and also this item.*" In reality, the query engine evaluates each row individually:

1.  Row 4: Is `item_name` equal to Bike? **Yes (**`TRUE`**)**.
    
2.  Is Row 4 *also* equal to Gaming Console? **No (**`FALSE`**)**.
    
3.  `TRUE AND FALSE = FALSE`. Row 4 discarded.
    

**Result:** Zero rows returned. You get a lecture on personal finance before the exam even starts.

![](https://cdn.hashnode.com/uploads/covers/6a985257c384f37738abcc7f/830e4871-43b5-45aa-98dd-6034074f32a6.png align="center")

**Act 3: The Final Exam Scam — Operator Precedence**

This brings us to the ultimate childhood betrayal: the **Final Examination** negotiation.

You sit down before finals. You hammer out what feels like an airtight verbal contract:

> "If you score 90% or higher, you can get a Mountain Bike OR a Gaming Console!"

You study late into the night. You memorize entire chapters. The final report card arrives: **94%**.

You walk into the living room, ready to claim your prize. You assumed your agreement was wrapped in safe, intuitive groupings.

**What You Thought You Negotiated**:

```plaintext
SELECT item_name, estimated_cost
FROM childhood_rewards
WHERE (item_name = 'Mountain Bike' OR item_name = 'Gaming Console')
  AND min_grade_percent <= 94;
```

In your mind, the `OR` was evaluated first:

1.  The pool of acceptable prizes was either the Bike or the Console.
    
2.  That pool was checked against your exam score (`min_grade_percent <= 94`).
    
3.  The Bike unlocks cleanly at 90%!
    

**What Your Parents Actually Executed:**

In relational databases, `AND` has a higher operator precedence than `OR` (just like multiplication takes precedence over addition in basic math).

If you do not explicitly place parentheses `()`, SQL binds the `AND` first:

```plaintext
SELECT item_name, estimated_cost
FROM childhood_rewards
WHERE item_name = 'Mountain Bike'
   OR item_name = 'Gaming Console' 
  AND min_grade_percent <= 94;
```

`AND min_grade_percent <= 94;`  
Because `AND` binds tighter, the engine interprets the expression like this:

```plaintext
WHERE item_name = 'Mountain Bike'
   OR (item_name = 'Gaming Console' AND min_grade_percent <= 94);
```

Look closely at what happens to Row 5 (Gaming Console):

1.  Does it satisfy `min_grade_percent <= 94`? **No, the Console requires 95%**.
    
2.  The `(Gaming Console AND min_grade_percent <= 94)` clause evaluates to `FALSE`.
    

Now look at Row 4 (Mountain Bike):

1.  It sits on the left side of the `OR: WHERE item_name = 'Mountain Bike'`.
    
2.  There is **no score constraint bound to it**.
    
3.  Your parent looks up from their coffee with an unblinking, deadpan stare: *"Wait, you thought the bike was tied to your 94%? The bike was an unconstrained luxury row. It exceeds the household capital reserve budget. Condition rejected."*
    
    ```plaintext
    +-----------------------+----------------+
    | item_name             | estimated_cost |
    +-----------------------+----------------+
    | Brown Book Cover Roll | 5              |
    +-----------------------+----------------+
    1 row in set (0.00 sec)
    ```
    
    **The living room output:** *"Next year's curriculum is the one that actually counts for college anyway. Here are the brown paper rolls for your new textbooks. Go cover them."*
    

**Execution time:** 14 years.

![](https://cdn.hashnode.com/uploads/covers/6a985257c384f37738abcc7f/1eefb95b-f3d4-44a7-aa85-8c3f25733be3.png align="center")

**The Golden Rule of Boolean Logic:**

Whenever you write a query combining `AND`and `OR`:

1.  **Never trust operator precedence to memory.** Even if you know `AND` executes before `OR`, the next developer reading your code will misread it.
    
2.  Always wrap your intentions in explicit parentheses `()`.
    
    1.  Want either item under a strict threshold? Group them:  
        `(item = 'A' OR item = 'B') AND score >= 90`.
        
    2.  Want independent alternative rules? Group each block:  
        `(item = 'A' AND cost < 100) OR (item = 'B' AND cost < 50)`.
        
3.  **Parentheses are free; database miscalculations are expensive.**
    

Life moves on, but your queries don't have to crash production.

☕ **Support the Series**  
If this breakdown brought back memories of childhood negotiations and saved your queries from bad logic, consider supporting the series:

[Buy StickDev a Coffee](https://ko-fi.com/knownuanceddetails)

Stay Nuanced!

![](https://cdn.hashnode.com/uploads/covers/6a985257c384f37738abcc7f/8a993bee-d49f-40f6-b856-3397d93cb153.png align="center")