end of day 3 week 1

week 1/day 2/exo1.py

@@ -1,3 +1,5 @@
+# Exo 1
+
 number = input("please enter an number :")
 
 if int(number) % 2:

week 1/day 2/exo5.md

@@ -0,0 +1,6 @@
+if the user name double in size
+the time of execution will double
+
+so the time of execution will be x 2
+
+T(m, n) = m x n

week 1/day3/exo1.sql

@@ -0,0 +1,2 @@
+-- exo 1
+SELECT * FROM users WHERE length(username) > 5 

week 1/day3/exo2.sql

@@ -0,0 +1,3 @@
+-- exo 2
+
+SELECT username FROM users WHERE username ~ '^[A-Za-z]+$';

week 1/day3/exo3.sql

@@ -0,0 +1,10 @@
+-- exo 3
+
+SELECT username,
+       CASE
+           WHEN length(username) <= 20
+                AND username ~ '^[A-Za-z]+$'
+           THEN 'Accepted'
+           ELSE 'Refused'
+       END AS status
+FROM users;

week 1/day3/exo4.sql

@@ -0,0 +1,3 @@
+SELECT Count(*) FROM users
+WHERE length(username) <= 20 
+AND  username ~ '^[A-Za-z]+$';

week 1/day3/exo5.md

@@ -0,0 +1,17 @@
+Answer in plain text:
+
+If the users table doubles in size, what happens to execution time?
+
+Write the runtime formula using:
+
+n = number of rows
+m = average username length
+
+if the number of user double a size
+the it mutiple by two the number of execution
+
+$$
+T(2n,m) = 2 \times n \times m
+$$
+
+Growth is linear

week 1/day3/init_db.sql

@@ -0,0 +1,14 @@
+CREATE TABLE users(
+    id SERIAL  PRIMARY KEY,
+    username TEXT
+);
+
+INSERT INTO users (username) VALUES
+('admin'),
+('root1'),
+('John_Doe'),
+('Alice'),
+('Bob42'),
+('charlie'),
+('eve99'),
+('Mallory');

week 1/day3/readme.md

@@ -0,0 +1,168 @@
+# 📘 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).