169 lines
3.5 KiB
Markdown
169 lines
3.5 KiB
Markdown
# 📘 Week 1 · Day 3 — SQL Exercises
|
||
|
||
This document describes **all exercises for Week 1 Day 3**, focused on **SQL conditionals, filtering, and algorithmic thinking** using **PostgreSQL**.
|
||
|
||
The goal of today’s exercises is to translate the control-flow logic you used in **C (Day 1)** and **Python (Day 2)** into **declarative SQL queries**, while keeping the same performance and security mindset.
|
||
|
||
---
|
||
|
||
## 🎯 Learning Objectives
|
||
|
||
By completing today’s exercises, you practice:
|
||
|
||
* Replacing loops with SQL filtering (`WHERE`)
|
||
* Using conditions to select and classify data
|
||
* Understanding how databases execute algorithms internally
|
||
* Reasoning about runtime complexity in a data-driven context
|
||
* Applying validation logic at the database layer (security best practice)
|
||
|
||
---
|
||
|
||
## 🛠 Database Setup (Reference)
|
||
|
||
All exercises assume the following PostgreSQL table:
|
||
|
||
inti_db.sql
|
||
|
||
```sql
|
||
CREATE TABLE users (
|
||
id SERIAL PRIMARY KEY,
|
||
username TEXT
|
||
);
|
||
```
|
||
|
||
Sample data:
|
||
|
||
```sql
|
||
INSERT INTO users (username) VALUES
|
||
('admin'),
|
||
('root1'),
|
||
('John_Doe'),
|
||
('Alice'),
|
||
('Bob42'),
|
||
('charlie'),
|
||
('eve99'),
|
||
('Mallory');
|
||
```
|
||
|
||
---
|
||
|
||
## 🧪 Exercises
|
||
|
||
### Exercise 1 — Length Filtering
|
||
|
||
**Task:**
|
||
Select all usernames that are **longer than 5 characters**.
|
||
|
||
**Concepts practiced:**
|
||
|
||
* `WHERE` clause
|
||
* String length evaluation
|
||
|
||
---
|
||
|
||
### Exercise 2 — Letters-Only Usernames
|
||
|
||
**Task:**
|
||
Select usernames that:
|
||
|
||
* Contain **only letters (A–Z, a–z)**
|
||
* Contain **no digits**
|
||
* Contain **no underscores or symbols**
|
||
|
||
**Concepts practiced:**
|
||
|
||
* Regular expressions in PostgreSQL
|
||
* Character validation at the database level
|
||
* Replacing character-by-character loops with pattern matching
|
||
|
||
---
|
||
|
||
### Exercise 3 — Accepted vs Refused Classification
|
||
|
||
**Task:**
|
||
Return a result set containing:
|
||
|
||
* `username`
|
||
* `status` column with values:
|
||
|
||
* `Accepted`
|
||
* `Refused`
|
||
|
||
**Rules:**
|
||
|
||
* Username length ≤ 20
|
||
* Username contains letters only
|
||
|
||
**Concepts practiced:**
|
||
|
||
* `CASE WHEN` expressions
|
||
* Conditional logic inside SQL queries
|
||
* Translating `if / else` into declarative form
|
||
|
||
---
|
||
|
||
### Exercise 4 — Count Valid Usernames
|
||
|
||
**Task:**
|
||
Return **only the number** of usernames that are valid according to the same rules:
|
||
|
||
* Length ≤ 20
|
||
* Letters only
|
||
|
||
**Concepts practiced:**
|
||
|
||
* Aggregate functions (`COUNT`)
|
||
* Combining filtering and aggregation
|
||
* Thinking about algorithm cost without explicit loops
|
||
|
||
---
|
||
|
||
### Exercise 5 — Algorithm Analysis (Written)
|
||
|
||
**Task:**
|
||
Answer the following questions:
|
||
|
||
1. If the `users` table **doubles in size**, what happens to the execution time?
|
||
2. Write the runtime formula using:
|
||
|
||
* `n` = number of rows
|
||
* `m` = average username length
|
||
|
||
**Expected reasoning:**
|
||
|
||
* SQL engines still scan rows internally
|
||
* Regex checks still evaluate characters
|
||
|
||
**Expected formula:**
|
||
|
||
```
|
||
T(n, m) = n × m
|
||
```
|
||
|
||
Explain this **in plain language**, from a sysadmin or security perspective.
|
||
|
||
---
|
||
|
||
## 🔐 Security Perspective
|
||
|
||
These exercises demonstrate why **validating data in SQL** is powerful:
|
||
|
||
* Reduces reliance on frontend-only checks
|
||
* Prevents bad data from entering critical systems
|
||
* Improves consistency across applications
|
||
* Aligns with real-world authentication, logging, and SIEM pipelines
|
||
|
||
---
|
||
|
||
## ✅ Completion Criteria
|
||
|
||
Day 3 is considered complete when:
|
||
|
||
* All four SQL queries execute correctly
|
||
* The algorithm explanation clearly explains scaling behavior
|
||
* The student can explain how SQL replaces procedural loops
|
||
|
||
---
|
||
|
||
**Next Step:** Week 1 Day 4 — deeper control flow and scripting (Bash or Rust, depending on track).
|