From db0f693eeb93ecd40e874d89decb65940e7c2b2c Mon Sep 17 00:00:00 2001 From: Ajay Dhangar Date: Fri, 13 Mar 2026 23:09:47 +0530 Subject: [PATCH] ADD-DOCS: content created for R-DBMS --- .../relational-databases/_category_.json | 8 ++ .../relational-databases/acid-properties.mdx | 68 +++++++++++ .../database-migrations.mdx | 107 ++++++++++++++++++ .../indexes-and-performance.mdx | 97 ++++++++++++++++ .../relational-databases/intro-to-rdbms.mdx | 101 +++++++++++++++++ .../relational-databases/normalization.mdx | 78 +++++++++++++ .../popular-databases.mdx | 78 +++++++++++++ .../relational-databases/sql-the-language.mdx | 106 +++++++++++++++++ 8 files changed, 643 insertions(+) create mode 100644 absolute-beginners/backend-beginner/relational-databases/_category_.json create mode 100644 absolute-beginners/backend-beginner/relational-databases/acid-properties.mdx create mode 100644 absolute-beginners/backend-beginner/relational-databases/database-migrations.mdx create mode 100644 absolute-beginners/backend-beginner/relational-databases/indexes-and-performance.mdx create mode 100644 absolute-beginners/backend-beginner/relational-databases/intro-to-rdbms.mdx create mode 100644 absolute-beginners/backend-beginner/relational-databases/normalization.mdx create mode 100644 absolute-beginners/backend-beginner/relational-databases/popular-databases.mdx create mode 100644 absolute-beginners/backend-beginner/relational-databases/sql-the-language.mdx diff --git a/absolute-beginners/backend-beginner/relational-databases/_category_.json b/absolute-beginners/backend-beginner/relational-databases/_category_.json new file mode 100644 index 0000000..d773b2a --- /dev/null +++ b/absolute-beginners/backend-beginner/relational-databases/_category_.json @@ -0,0 +1,8 @@ +{ + "label": "Relational Databases", + "position": 7, + "link": { + "type": "generated-index", + "description": "Learn how to store data in structured tables, use SQL to query information, and understand why RDBMS is the backbone of the banking and enterprise world." + } +} \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/relational-databases/acid-properties.mdx b/absolute-beginners/backend-beginner/relational-databases/acid-properties.mdx new file mode 100644 index 0000000..5749b41 --- /dev/null +++ b/absolute-beginners/backend-beginner/relational-databases/acid-properties.mdx @@ -0,0 +1,68 @@ +--- +sidebar_position: 3 +title: "ACID Properties: The DNA of RDBMS" +sidebar_label: "3. ACID Properties" +description: "Learn the four essential rules that keep your database safe and reliable." +--- + +In India, we use apps like **PhonePe, GPay, or Paytm** every single day. Have you ever wondered what happens if your internet cuts out exactly when you are sending ₹500 to a friend? + +Does the money vanish? Does it get stuck in the "middle"? + +**No.** This is thanks to **ACID Properties**. These are the 4 golden rules that every Relational Database must follow to ensure your data is 100% safe. + +## The 4 Pillars of ACID + +### 1. Atomicity (The "All or Nothing" Rule) + +In a database, a "Transaction" is a series of steps. Atomicity ensures that either **every step** happens, or **none** of them do. + +**The Real-World Example:** +Imagine you are transferring ₹500 to your friend Rahul. +1. Bank deducts ₹500 from your account. +2. **Server Crashes!** +3. Bank fails to add ₹500 to Rahul's account. + +Because of **Atomicity**, the database will "Rollback." It sees the crash, cancels the first step, and puts the ₹500 back in your account as if nothing ever happened. + +### 2. Consistency (The "Follow the Rules" Rule) + +Every database has rules (Constraints). Consistency ensures that a transaction never leaves the database in a "weird" state. + +**The Real-World Example:** +If your bank has a rule that "Balance cannot be negative," and you try to send ₹1000 when you only have ₹500, the database will block the transaction immediately. The rules stay intact! + +### 3. Isolation (The "No Cutting in Line" Rule) + +Modern databases handle thousands of users at the same time. Isolation ensures that one person's transaction doesn't "leak" into another's. + +**The Real-World Example:** +Imagine there is only **1 last seat** left on a bus from Delhi to Mumbai. +* You and another person click "Book" at the exact same microsecond. +* **Isolation** makes them wait in a digital line. One person gets the seat, and the other gets a "Sold Out" message. They don't both get charged for the same seat! + +### 4. Durability (The "Saved Forever" Rule) + +Once the database tells you "Transaction Successful," that data is permanent. + +**The Real-World Example:** +Even if the bank's data center loses power or a server explodes 1 second after your transaction is finished, your balance will still be correct when the power comes back. The record is written to a permanent disk, not just temporary memory. + +## Summary Table + +| Property | Short Meaning | "Desi" Analogy | +| :--- | :--- | :--- | +| **A**tomicity | All or Nothing | Like a 'Paisa Vasool' deal—you get everything promised or your money back. | +| **C**onsistency | Data Integrity | No "Jugaad" allowed—the rules are the rules. | +| **I**solation | Separate Work | Mind your own business—don't let others' work mix with yours. | +| **D**urability | Permanent Save | Written in stone—even if the world ends, the record stays. | + +## Summary Checklist +* [x] I understand that ACID keeps data safe during crashes. +* [x] I know that "Atomicity" prevents partial updates. +* [x] I understand why "Isolation" is needed for many users. +* [x] I recognize that "Durability" means the data is permanent. + +:::tip Career Advice +Interviewers love asking about ACID. If you explain it using the "Bank Transfer" example like we did here, you will show them that you don't just memorize definitions—you actually understand how the real world works! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/relational-databases/database-migrations.mdx b/absolute-beginners/backend-beginner/relational-databases/database-migrations.mdx new file mode 100644 index 0000000..933024a --- /dev/null +++ b/absolute-beginners/backend-beginner/relational-databases/database-migrations.mdx @@ -0,0 +1,107 @@ +--- +sidebar_position: 6 +title: "Database Migrations" +sidebar_label: "6. Migrations" +description: "Learn how to track and manage changes to your database schema using version control for data." +--- + +Have you ever added a new column to a table on your laptop, but then your teammate's code crashed because *their* database didn't have that column? + +In the old days, you had to send a `.sql` file to your friend and say, "Hey, run this command." **Database Migrations** solve this problem by automating the process. + +## 🧐 What is a Migration? + +A **Migration** is a small script (usually in JavaScript, Python, or SQL) that describes a specific change to your database structure. + +* **Migration Files** are kept in your GitHub repository. +* When a teammate pulls your code, they run one command, and their database is instantly updated to match yours. + +## How Migrations Work: UP and DOWN + +Every migration file has two main functions: + +1. **UP:** What should happen when we apply the migration? (e.g., Create a table). +2. **DOWN:** How do we "Undo" this change if we made a mistake? (e.g., Drop the table). + + + + + ```javascript + // Adding a 'phone_number' column to the Users table + export async function up(knex) { + return knex.schema.table('users', (table) => { + table.string('phone_number').nullable(); + }); + } + + // Undoing the change + export async function down(knex) { + return knex.schema.table('users', (table) => { + table.dropColumn('phone_number'); + }); + } + +``` + + + + +```sql +-- UP: Apply the change +ALTER TABLE Users ADD COLUMN phone_number VARCHAR(15); + +-- DOWN: Undo the change +ALTER TABLE Users DROP COLUMN phone_number; + +``` + + + + +--- + +## The Migration Workflow + +At **CodeHarborHub**, we follow this industrial workflow to keep our data in sync: + +1. **Create:** You generate a new migration file (e.g., `20260313_add_bio_to_users.js`). +2. **Write:** You define the `up` and `down` logic. +3. **Run:** You execute the migration command (e.g., `npx knex migrate:latest`). +4. **Commit:** You push the migration file to **GitHub**. +5. **Sync:** Your teammates pull the code and run the same command. **Boom! Everyone is on the same page.** + +```mermaid +sequenceDiagram + participant DevA as Developer A + participant GH as GitHub (Code) + participant DevB as Developer B + + DevA->>DevA: Creates Migration Script + DevA->>DevA: Runs 'Migrate' (Local DB updated) + DevA->>GH: Pushes Script to Repo + GH->>DevB: Pulls Code + DevB->>DevB: Runs 'Migrate' (Local DB updated) + Note over DevA,DevB: Both Databases are now identical! + +``` + +--- + +## Why You Should NEVER Edit Tables Manually + +If you go into your database tool (like pgAdmin or MySQL Workbench) and manually add a column: + +* **Production will crash:** When you deploy your code, the live server won't have that column. +* **Loss of History:** You won't know *when* or *why* that change was made. +* **Team Friction:** Your teammates will constantly get "Table not found" errors. + +## Summary Checklist + +* [x] I understand that Migrations are "Version Control" for my database. +* [x] I know that `up` applies changes and `down` reverts them. +* [x] I understand that migration files should be committed to GitHub. +* [x] I promise to never manually edit my database schema in production. + +:::tip Career Secret +In a job interview, if you mention that you use **Migrations** to manage your schema instead of manual SQL scripts, you immediately look like a 10x more experienced developer. It shows you know how to work in a **real team**. +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/relational-databases/indexes-and-performance.mdx b/absolute-beginners/backend-beginner/relational-databases/indexes-and-performance.mdx new file mode 100644 index 0000000..75df01e --- /dev/null +++ b/absolute-beginners/backend-beginner/relational-databases/indexes-and-performance.mdx @@ -0,0 +1,97 @@ +--- +sidebar_position: 7 +title: "Indexes & Query Performance" +sidebar_label: "7. Performance" +description: Learn "how to make your database queries lightning fast using Indexes and execution analysis." +--- + +Imagine you are in a massive library with 1,000,000 books. If you want to find a book about "Node.js," you don't start at the first shelf and check every book. You go to the **Index Catalog** at the front, find the shelf number, and go straight there. + +In a database, an **Index** does exactly the same thing. + +## What is an Index? + +An index is a separate data structure (usually a **B-Tree**) that stores a sorted version of a specific column. This allows the database to "jump" to the data instead of scanning the whole table. + +### ✅ Pros: + +* **Speed:** Searching becomes 100x to 1000x faster. +* **Efficiency:** Reduces the load on your server's CPU and Memory. + +### ❌ Cons: + +* **Storage:** Indexes take up extra disk space. +* **Write Speed:** Every time you `INSERT` or `UPDATE`, the database has to update the index too. **Don't index every column!** + +## How to Create an Index + + + + + If you frequently search for users by their email, add an index to the `email` column. + + ```sql + CREATE INDEX idx_user_email ON Users(email); + ``` + + + + +If you often search for people using both `first_name` AND `last_name`, a composite index is better. + +```sql +CREATE INDEX idx_full_name ON Users(first_name, last_name); + +``` + + + + +## Performance Analysis: The `EXPLAIN` Command + +How do you know if your query is actually using an index or being slow? You ask the database to explain its "Query Plan." + +```sql +EXPLAIN ANALYZE +SELECT * FROM Users WHERE email = 'aryan@codeharborhub.github.io'; +``` + +**What to look for in the output:** + +* **Seq Scan (Sequential Scan):** BAD. The DB is reading every row in the table. +* **Index Scan:** GOOD. The DB is using your index to find the data instantly. +* **Cost:** Lower is better! + +## Top 3 Performance Tips for Backend Devs + +### 1. Avoid `SELECT *` + +Only ask for the columns you need. + +* `SELECT * FROM Users;` (Heavy and slow) +* `SELECT name, email FROM Users;` (Light and fast) + +### 2. Use `LIMIT` + +If you have 1 million users, don't fetch them all at once. Use pagination. + +```sql +SELECT * FROM Users LIMIT 10 OFFSET 0; +``` + +### 3. Index your Foreign Keys + +Always create an index on columns used in `JOIN` operations. This prevents the database from getting confused when linking large tables. + +## Summary Checklist + +* [x] I understand that an Index is like a library catalog for my data. +* [x] I know that Indexes speed up **Reads** but slow down **Writes**. +* [x] I can use `EXPLAIN ANALYZE` to check my query performance. +* [x] I know why `SELECT *` is a "Red Flag" in professional code. + +:::tip Interview Secret +If a Senior Developer asks you "How do you optimize a slow API?", your first answer should always be: **"I would check the database logs and see if we need to add an Index or optimize the SQL query using EXPLAIN."** +::: + +**Congratulations!** You've completed the Relational Database Module. \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/relational-databases/intro-to-rdbms.mdx b/absolute-beginners/backend-beginner/relational-databases/intro-to-rdbms.mdx new file mode 100644 index 0000000..a115c5a --- /dev/null +++ b/absolute-beginners/backend-beginner/relational-databases/intro-to-rdbms.mdx @@ -0,0 +1,101 @@ +--- +sidebar_position: 1 +title: "Introduction to RDBMS" +sidebar_label: "1. What is RDBMS?" +description: "The fundamental building blocks of Relational Database Management Systems for beginners." +--- + +In the world of Backend Development, data is everything. But how do we store it so that it stays organized, secure, and easy to find? We use a **Relational Database Management System (RDBMS)**. + +## 🧐 The "Spreadsheet" Analogy + +The easiest way to understand a Relational Database is to think of it as a collection of **Excel Spreadsheets** that are linked together. + +Imagine you are running a school: +* One sheet for **Students** (Name, Roll No, Age). +* One sheet for **Courses** (Course Name, Teacher). +* One sheet for **Enrollments** (Which Student is in which Course). + +Instead of repeating a student's name 10 times, you just link their unique **Roll Number**. That is the "Relationship" in Relational Database! + +## Core Components of RDBMS + +Every Relational Database is built using these three specific parts: + + + + The basic container. Everything in RDBMS is a table. + * **Rows (Records):** Represent a single item (e.g., One specific student). + * **Columns (Fields):** Represent a property (e.g., Student's Email). + + + Keys are the "Glue" that holds tables together. + * **Primary Key (PK):** A unique ID that identifies a specific row (e.g., Roll No). + * **Foreign Key (FK):** A link used to refer to a Primary Key in another table. + + + Rules that the data must follow. + * **NOT NULL:** This column cannot be empty. + * **UNIQUE:** No two rows can have the same value in this column. + + + +## Visualizing the Relationship + +Using a **Mermaid Diagram**, we can see how an E-commerce database actually "relates" different tables: + +```mermaid +erDiagram + USER ||--o{ ORDER : places + ORDER ||--|{ PRODUCT : contains + USER { + string username + string email PK + string password + } + ORDER { + int order_id PK + string user_email FK + date created_at + } + PRODUCT { + int product_id PK + string name + float price + } + +``` + +## Why do we use RDBMS? + +:::tip The Golden Rule +If your data is **structured** (fits into rows and columns) and needs to be **100% accurate** (like a bank balance), use an RDBMS. +::: + +1. **Data Integrity:** It ensures that you cannot delete a user if they still have active orders. +2. **Scalability:** Modern RDBMS like PostgreSQL can handle millions of rows without slowing down. +3. **Security:** You can control exactly who can read or write to specific tables. +4. **Standard Language:** Almost every RDBMS uses **SQL**, making your skills transferable. + +## ACID: The Security Shield + +Relational Databases follow the **ACID** principle to ensure that even if the server crashes, your data remains safe. + +:::info Quick Definition + +* **Atomicity:** All parts of a transaction succeed, or none do. +* **Consistency:** Data follows all defined rules. +* **Isolation:** Transactions don't interfere with each other. +* **Durability:** Once saved, data stays saved even during power failure. +::: + +## Summary Checklist + +* [x] I know that RDBMS stands for Relational Database Management System. +* [x] I understand that tables are linked using **Primary** and **Foreign Keys**. +* [x] I recognize that data is stored in Rows and Columns. +* [x] I understand why ACID properties are important for data safety. + +:::note Homework +Think about a Social Media app like Instagram. What tables would you need? (Hint: Users, Posts, Comments). Try to imagine which columns would be the "Primary Keys"! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/relational-databases/normalization.mdx b/absolute-beginners/backend-beginner/relational-databases/normalization.mdx new file mode 100644 index 0000000..5a5c48e --- /dev/null +++ b/absolute-beginners/backend-beginner/relational-databases/normalization.mdx @@ -0,0 +1,78 @@ +--- +sidebar_position: 5 +title: "Database Normalization" +sidebar_label: "5. Normalization" +description: "Learn how to organize your database tables to reduce redundancy and improve data integrity." +--- + +Have you ever seen a messy room where everything is piled up in one corner? It’s impossible to find anything! A "messy" database is just like that. **Normalization** is the process of organizing data into multiple related tables to clean up that mess. + +## Why do we Normalize? + +1. **Remove Redundancy:** We don't want to type the same information (like a teacher's phone number) in 50 different rows. +2. **Data Integrity:** If a student changes their email, we should only have to update it in **one** place. +3. **Efficiency:** Smaller tables are faster for the database to search through. + +## The Three Stages (Normal Forms) + +We usually normalize databases up to the **3rd Normal Form (3NF)**. Let's look at them step-by-step. + + + + + ### Rule: "Atomic Values Only" + Each cell in your table must contain only **one** piece of information. No lists or comma-separated values! + + ❌ **Bad (Not 1NF):** + | Student | Courses | + | :--- | :--- | + | Aryan | Math, Science | + + ✅ **Good (1NF):** + | Student | Course | + | :--- | :--- | + | Aryan | Math | + | Aryan | Science | + + + + + ### Rule: "Fully Depend on the Primary Key" + Must be in 1NF + remove data that only partialy depends on a composite primary key. In simple terms: **Split the table** if it's talking about two different things. + + *Example:* Don't store "Course Teacher" in the "Students" table. Create a separate `Courses` table. + + + + + ### Rule: "No Transitive Dependencies" + Must be in 2NF + non-key columns shouldn't depend on other non-key columns. + + *Analogy:* If Column A determines Column B, and Column B determines Column C, then Column C shouldn't be in the same table as Column A! + + + + +## The "Desi" Summary (The Key Oath) + +There is a famous saying by Bill Kent to help you remember the rules of normalization. For our Indian students, think of it as a **"Pavitra Kasam" (Sacred Oath)**: + +> "I promise to design my tables so that every column depends on **The Key** (1NF), **The Whole Key** (2NF), and **Nothing But The Key** (3NF), so help me Codd!" + +## Before vs. After Normalization + +| Problem | Normalization Solution | +| :--- | :--- | +| **Updating is hard** | You only update data in one place. | +| **Deleting is dangerous** | Deleting a student won't accidentally delete the whole course. | +| **Wasted Space** | No more repeating long strings of text in every row. | + +## Summary Checklist +* [x] I understand that Normalization reduces data repetition. +* [x] I know that 1NF means no lists in a single cell. +* [x] I understand that 2NF and 3NF are about splitting tables logically. +* [x] I can explain the "Key Oath" for designing tables. + +:::warning Don't Over-Normalize! +In the real world, sometimes developers "De-normalize" (make things messy on purpose) to make the database **even faster** for specific types of searches. But for now, always aim for **3NF**! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/relational-databases/popular-databases.mdx b/absolute-beginners/backend-beginner/relational-databases/popular-databases.mdx new file mode 100644 index 0000000..a9bcb6b --- /dev/null +++ b/absolute-beginners/backend-beginner/relational-databases/popular-databases.mdx @@ -0,0 +1,78 @@ +--- +sidebar_position: 4 +title: "Popular RDBMS: Choosing Your Tool" +sidebar_label: "4. Popular Databases" +description: "Compare the most popular Relational Database engines like PostgreSQL, MySQL, and SQLite." +--- + +Not all Relational Databases are the same. While they all use SQL, they are built for different purposes. At **CodeHarborHub**, we want you to pick the right tool for your specific project. + +## The "Big Three" Comparison + + + + + ### The "Gold Standard" + PostgreSQL (or Postgres) is the most advanced open-source database. It is famous for being extremely reliable and feature-rich. + + * **Best For:** Complex applications, data analysis, and large-scale backends. + * **Killer Feature:** It handles "JSON" data very well, almost like a NoSQL database. + * **Pro Tip:** If you aren't sure which one to pick, **choose Postgres**. It's the industry favorite for a reason. + + + + + ### The "Web Pioneer" + MySQL is the world's most popular database for web applications. It powers giants like **Facebook, YouTube, and WordPress**. + + * **Best For:** Standard web apps, blogs, and e-commerce sites. + * **Killer Feature:** Extremely fast for "Read-Heavy" applications (where users are mostly looking at data rather than changing it). + * **Pro Tip:** Great for beginners because it has massive community support and hosting is very cheap. + + + + + ### The "Lightweight" + SQLite is unique because it isn't a "Server." It’s just a **single file** that sits in your project folder. + + * **Best For:** Mobile apps (Android/iOS), IoT devices, and local testing. + * **Killer Feature:** Zero configuration! You don't need to install or manage a database server. + * **Pro Tip:** Use this during development to move fast, then switch to Postgres for production. + + + + +## Feature Matrix + +| Feature | PostgreSQL | MySQL | SQLite | +| :--- | :--- | :--- | :--- | +| **Type** | Client-Server | Client-Server | Serverless (File-based) | +| **Performance** | High (Write/Read) | High (Read) | Medium | +| **Difficulty** | Medium | Easy | Very Easy | +| **JSON Support** | Excellent | Good | Limited | +| **Concurrency** | Amazing (Many Users) | High | Low (One writer at a time) | + +## Which one should you pick for your project? + +```mermaid +graph TD + Start[Choose a Database] --> A{Is it a Mobile App?} + A -- Yes --> SQLite[SQLite] + A -- No --> B{Is it a simple Blog/WP?} + B -- Yes --> MySQL[MySQL] + B -- No --> C{Complex Data/Enterprise?} + C -- Yes --> Postgres[PostgreSQL] + C -- No --> Postgres + +``` + +## Summary Checklist + +* [x] I understand that **PostgreSQL** is the most powerful and feature-rich. +* [x] I know that **MySQL** is the most popular for web applications. +* [x] I recognize that **SQLite** is perfect for local testing and mobile apps. +* [x] I can choose a database based on my project's complexity. + +:::info Fun Fact +Did you know that **SQLite** is the most deployed database in the world? Every single Android phone and iPhone has multiple SQLite databases inside it to store your messages, contacts, and settings! +::: \ No newline at end of file diff --git a/absolute-beginners/backend-beginner/relational-databases/sql-the-language.mdx b/absolute-beginners/backend-beginner/relational-databases/sql-the-language.mdx new file mode 100644 index 0000000..f94c9a5 --- /dev/null +++ b/absolute-beginners/backend-beginner/relational-databases/sql-the-language.mdx @@ -0,0 +1,106 @@ +--- +sidebar_position: 2 +title: "SQL - The Language of Data" +sidebar_label: "2. SQL Basics" +description: "Master the syntax and commands of Structured Query Language (SQL) for backend development." +--- + +**SQL** (Structured Query Language) is the universal language used to communicate with Relational Databases. Whether you use MySQL, PostgreSQL, or SQL Server, the way you ask for data is 95% the same. + +## The 4 Pillars: CRUD Operations + +In backend development, almost everything you do with a database falls into one of four categories: **CRUD**. + + + + + Use the `INSERT` command to add new records to a table. + + ```sql + INSERT INTO Students (name, email, age) + VALUES ('Aryan Kumar', 'aryan@codeharborhub.github.io', 21); + ``` + + + + +Use the `SELECT` command to retrieve data. You can filter results using `WHERE`. + +```sql +-- Get everyone's name and email +SELECT name, email FROM Students; + +-- Get only the student with a specific ID +SELECT * FROM Students WHERE id = 1; + +``` + + + + +Use the `UPDATE` command to modify existing data. **Always use a WHERE clause** or you will update every single row! + +```sql +UPDATE Students +SET email = 'new-aryan@gmail.com' +WHERE id = 1; + +``` + + + + +Use the `DELETE` command to remove records. Again, the `WHERE` clause is your best friend here. + +```sql +DELETE FROM Students +WHERE id = 1; + +``` + + + + +## Joining the Dots: SQL JOINS + +The true power of SQL is its ability to combine data from multiple tables. This is called a **JOIN**. + +Imagine you have a `Students` table and a `Courses` table. To see which student is in which course, you link them: + +```sql +SELECT Students.name, Courses.course_name +FROM Students +JOIN Enrollments ON Students.id = Enrollments.student_id +JOIN Courses ON Enrollments.course_id = Courses.id; +``` + +## Filtering and Sorting + +SQL allows you to organize your data exactly how you want it. + +* **ORDER BY:** Sort your results (e.g., `ORDER BY age DESC`). +* **LIMIT:** Only get a specific number of rows (great for pagination). +* **LIKE:** Search for patterns (e.g., `WHERE name LIKE 'A%'` finds all names starting with A). + +## Advanced Data Manipulation + +Sometimes you need to perform math or group data together. + +```sql +-- Count how many students are in the database +SELECT COUNT(*) FROM Students; + +-- Find the average age of students +SELECT AVG(age) FROM Students; +``` + +## Summary Checklist + +* [x] I understand that SQL is the language used to manage RDBMS. +* [x] I can explain what CRUD stands for. +* [x] I know the danger of running `UPDATE` or `DELETE` without a `WHERE` clause. +* [x] I understand how `JOIN` combines data from different tables. + +:::warning Professional Warning +In a real production environment, never use `SELECT *` (Select All) if you only need one or two columns. Selecting only what you need makes your application much faster and saves memory! +::: \ No newline at end of file