diff --git a/docs/sql/SQL-joins/assets/cross-join.gif b/docs/sql/SQL-joins/assets/cross-join.gif
new file mode 100644
index 00000000..c523d541
Binary files /dev/null and b/docs/sql/SQL-joins/assets/cross-join.gif differ
diff --git a/docs/sql/SQL-joins/assets/full-outer-join.gif b/docs/sql/SQL-joins/assets/full-outer-join.gif
new file mode 100644
index 00000000..7712e2a3
Binary files /dev/null and b/docs/sql/SQL-joins/assets/full-outer-join.gif differ
diff --git a/docs/sql/SQL-joins/assets/inner-join.png b/docs/sql/SQL-joins/assets/inner-join.png
new file mode 100644
index 00000000..474b6769
Binary files /dev/null and b/docs/sql/SQL-joins/assets/inner-join.png differ
diff --git a/docs/sql/SQL-joins/assets/intro-sql-joins.png b/docs/sql/SQL-joins/assets/intro-sql-joins.png
new file mode 100644
index 00000000..524b9096
Binary files /dev/null and b/docs/sql/SQL-joins/assets/intro-sql-joins.png differ
diff --git a/docs/sql/SQL-joins/assets/left-outer-join.png b/docs/sql/SQL-joins/assets/left-outer-join.png
new file mode 100644
index 00000000..0e5427fa
Binary files /dev/null and b/docs/sql/SQL-joins/assets/left-outer-join.png differ
diff --git a/docs/sql/SQL-joins/assets/right-join.gif b/docs/sql/SQL-joins/assets/right-join.gif
new file mode 100644
index 00000000..4988449b
Binary files /dev/null and b/docs/sql/SQL-joins/assets/right-join.gif differ
diff --git a/docs/sql/SQL-joins/assets/self-join.png b/docs/sql/SQL-joins/assets/self-join.png
new file mode 100644
index 00000000..c6fc3411
Binary files /dev/null and b/docs/sql/SQL-joins/assets/self-join.png differ
diff --git a/docs/sql/SQL-joins/cross-join.md b/docs/sql/SQL-joins/cross-join.md
new file mode 100644
index 00000000..a346505e
--- /dev/null
+++ b/docs/sql/SQL-joins/cross-join.md
@@ -0,0 +1,378 @@
+---
+id: cross-join
+title: SQL CROSS JOIN #Remember to keep this unique, as it maps with giscus discussions in the recodehive/support/general discussions
+sidebar_label: CROSS JOIN #displays in sidebar
+sidebar_position: 6
+tags:
+ [
+ sql,
+ cross join,
+ sql cross join,
+ cartesian product,
+ join tables,
+ relational database,
+ sql tutorial,
+ database queries,
+ ]
+description: Learn about SQL CROSS JOIN, how it creates Cartesian products, syntax, examples, and when to use it for generating all possible combinations.
+---
+
+## What is CROSS JOIN?
+
+SQL **CROSS JOIN** produces the Cartesian product of two tables, returning all possible combinations of rows from both tables. Unlike other joins, CROSS JOIN doesn't require a join condition and combines every row from the first table with every row from the second table.
+
+:::note
+**Key Characteristics of CROSS JOIN:**
+
+- **Cartesian Product**: Creates all possible row combinations from both tables.
+
+- **No Join Condition**: Doesn't use ON or WHERE clauses for joining logic.
+
+- **Result Size**: Returns (Table1 rows × Table2 rows) total rows.
+
+- **Use With Caution**: Can quickly generate enormous result sets.
+:::
+
+
+ [](https://www.learnsqlonline.org/)
+
+
+:::success
+**When to Use CROSS JOIN:**
+
+- **Generating Combinations**: Creating all possible product-color combinations
+- **Time Series Data**: Pairing dates with entities for complete time series
+- **Report Templates**: Creating report structures with all possible categories
+- **Test Data Generation**: Creating comprehensive test datasets
+- **Mathematical Operations**: Matrix operations and mathematical calculations
+
+**Real-World Example:**
+A clothing retailer wants to create a product catalog showing all possible combinations of shirt styles (5 types) with available colors (8 colors), resulting in 40 unique product variants.
+:::
+
+:::warning
+**⚠️ Important Considerations:**
+
+CROSS JOIN can produce **very large result sets**:
+- 1,000 rows × 1,000 rows = 1,000,000 rows
+- 10,000 rows × 5,000 rows = 50,000,000 rows
+
+Always consider the size of your tables before using CROSS JOIN!
+:::
+
+:::info
+
+## Basic CROSS JOIN Syntax
+
+```sql
+-- Method 1: Using CROSS JOIN keyword
+SELECT column1, column2, ...
+FROM table1
+CROSS JOIN table2;
+
+-- Method 2: Using comma-separated tables (implicit cross join)
+SELECT column1, column2, ...
+FROM table1, table2;
+```
+
+| **Component** | **Purpose** | **Example** |
+|---------------|-------------|-------------|
+| SELECT | Choose columns to display | `SELECT p.name, c.color_name` |
+| FROM | First table | `FROM products p` |
+| CROSS JOIN | Second table | `CROSS JOIN colors c` |
+
+## Result Set Size Calculation
+
+| **Table 1 Rows** | **Table 2 Rows** | **Result Rows** |
+|-------------------|-------------------|-----------------|
+| 3 | 4 | 12 |
+| 10 | 5 | 50 |
+| 100 | 20 | 2,000 |
+| 1,000 | 1,000 | 1,000,000 |
+
+:::
+
+## Practical Examples
+
+
+
+ ```sql
+ -- Create all possible product-color combinations
+ SELECT
+ p.product_id,
+ p.product_name,
+ p.base_price,
+ c.color_id,
+ c.color_name,
+ c.color_hex,
+ (p.base_price + c.price_adjustment) AS final_price
+ FROM products p
+ CROSS JOIN colors c
+ WHERE p.category = 'Shirts'
+ ORDER BY p.product_name, c.color_name;
+
+ -- Result: Every shirt paired with every available color
+ ```
+
+
+ ```sql
+ -- Generate complete date series for all employees
+ SELECT
+ e.employee_id,
+ e.employee_name,
+ e.department,
+ d.date_value,
+ YEAR(d.date_value) AS year,
+ MONTH(d.date_value) AS month,
+ 'Pending' AS attendance_status
+ FROM employees e
+ CROSS JOIN (
+ SELECT DATE('2024-01-01') + INTERVAL (a.a + (10 * b.a)) DAY AS date_value
+ FROM (SELECT 0 AS a UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4
+ UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9) a,
+ (SELECT 0 AS a UNION SELECT 1 UNION SELECT 2 UNION SELECT 3 UNION SELECT 4
+ UNION SELECT 5 UNION SELECT 6 UNION SELECT 7 UNION SELECT 8 UNION SELECT 9
+ UNION SELECT 10 UNION SELECT 11 UNION SELECT 12 UNION SELECT 13
+ UNION SELECT 14 UNION SELECT 15 UNION SELECT 16 UNION SELECT 17
+ UNION SELECT 18 UNION SELECT 19 UNION SELECT 20 UNION SELECT 21
+ UNION SELECT 22 UNION SELECT 23 UNION SELECT 24 UNION SELECT 25
+ UNION SELECT 26 UNION SELECT 27 UNION SELECT 28 UNION SELECT 29
+ UNION SELECT 30 UNION SELECT 31 UNION SELECT 32 UNION SELECT 33
+ UNION SELECT 34 UNION SELECT 35 UNION SELECT 36) b
+ WHERE DATE('2024-01-01') + INTERVAL (a.a + (10 * b.a)) DAY <= '2024-12-31'
+ ) d
+ WHERE e.status = 'Active'
+ ORDER BY e.employee_id, d.date_value;
+ ```
+
+
+ ```sql
+ -- Generate all possible product configurations
+ SELECT
+ p.product_name,
+ s.size_name,
+ s.size_multiplier,
+ c.color_name,
+ m.material_name,
+ m.material_cost,
+ CONCAT(p.product_name, ' - ', s.size_name, ' - ', c.color_name, ' - ', m.material_name) AS sku_description,
+ (p.base_price * s.size_multiplier + c.price_adjustment + m.material_cost) AS final_price
+ FROM products p
+ CROSS JOIN sizes s
+ CROSS JOIN colors c
+ CROSS JOIN materials m
+ WHERE p.category = 'Custom Items'
+ AND s.available = 1
+ AND c.available = 1
+ AND m.available = 1
+ ORDER BY p.product_name, final_price DESC;
+ ```
+
+
+ ```sql
+ -- Create sales target matrix for all reps in all territories
+ SELECT
+ sr.rep_id,
+ sr.rep_name,
+ t.territory_id,
+ t.territory_name,
+ t.region,
+ t.base_target,
+ sr.experience_level,
+ CASE sr.experience_level
+ WHEN 'Senior' THEN t.base_target * 1.2
+ WHEN 'Mid-level' THEN t.base_target * 1.0
+ WHEN 'Junior' THEN t.base_target * 0.8
+ END AS adjusted_target,
+ CONCAT(sr.rep_name, ' - ', t.territory_name) AS assignment_code
+ FROM sales_reps sr
+ CROSS JOIN territories t
+ WHERE sr.status = 'Active'
+ AND t.status = 'Open'
+ ORDER BY t.region, sr.experience_level DESC, adjusted_target DESC;
+ ```
+
+
+ ```sql
+ -- Restaurant menu: all possible meal combinations
+ SELECT
+ a.item_name AS appetizer,
+ a.price AS appetizer_price,
+ m.item_name AS main_course,
+ m.price AS main_price,
+ d.item_name AS dessert,
+ d.price AS dessert_price,
+ (a.price + m.price + d.price) AS combo_price,
+ (a.price + m.price + d.price) * 0.9 AS discounted_price,
+ CONCAT(a.item_name, ' + ', m.item_name, ' + ', d.item_name) AS combo_name
+ FROM menu_items a
+ CROSS JOIN menu_items m
+ CROSS JOIN menu_items d
+ WHERE a.category = 'Appetizer'
+ AND m.category = 'Main Course'
+ AND d.category = 'Dessert'
+ AND a.available = 1
+ AND m.available = 1
+ AND d.available = 1
+ HAVING combo_price <= 50 -- Filter expensive combinations
+ ORDER BY combo_price;
+ ```
+
+
+ ```plaintext
+ -- Sample result for product-color cross join:
+
+ product_id | product_name | base_price | color_id | color_name | final_price
+ -----------|-----------------|------------|----------|------------|------------
+ 1 | Classic T-Shirt | 19.99 | 1 | Red | 21.99
+ 1 | Classic T-Shirt | 19.99 | 2 | Blue | 21.99
+ 1 | Classic T-Shirt | 19.99 | 3 | Green | 21.99
+ 1 | Classic T-Shirt | 19.99 | 4 | Black | 22.99
+ 2 | Premium Polo | 39.99 | 1 | Red | 41.99
+ 2 | Premium Polo | 39.99 | 2 | Blue | 41.99
+ 2 | Premium Polo | 39.99 | 3 | Green | 41.99
+ 2 | Premium Polo | 39.99 | 4 | Black | 42.99
+
+ -- Note: Every product appears with every color
+ -- 2 products × 4 colors = 8 total combinations
+ ```
+
+
+
+## Advanced CROSS JOIN Patterns
+
+:::tip
+**Complex Scenarios:**
+
+1. **Filtered Cross Join**:
+ ```sql
+ -- Create valid product combinations only
+ SELECT
+ p.product_name,
+ c.color_name,
+ s.size_name
+ FROM products p
+ CROSS JOIN colors c
+ CROSS JOIN sizes s
+ WHERE p.category = c.compatible_category
+ AND s.size_group = p.size_group
+ AND p.discontinued = 0;
+ ```
+
+2. **Cross Join with Aggregation**:
+ ```sql
+ -- Calculate distance matrix between all store locations
+ SELECT
+ s1.store_name AS from_store,
+ s2.store_name AS to_store,
+ SQRT(
+ POW(s1.latitude - s2.latitude, 2) +
+ POW(s1.longitude - s2.longitude, 2)
+ ) * 69 AS distance_miles -- Rough conversion
+ FROM stores s1
+ CROSS JOIN stores s2
+ WHERE s1.store_id != s2.store_id -- Exclude same store
+ ORDER BY distance_miles;
+ ```
+
+3. **Time Series with Cross Join**:
+ ```sql
+ -- Create complete monthly report template
+ SELECT
+ months.month_name,
+ months.month_number,
+ dept.department_name,
+ dept.budget,
+ 0 AS actual_spending, -- Placeholder for actual data
+ 'Pending' AS status
+ FROM (
+ SELECT 1 as month_number, 'January' as month_name
+ UNION SELECT 2, 'February' UNION SELECT 3, 'March'
+ UNION SELECT 4, 'April' UNION SELECT 5, 'May'
+ UNION SELECT 6, 'June' UNION SELECT 7, 'July'
+ UNION SELECT 8, 'August' UNION SELECT 9, 'September'
+ UNION SELECT 10, 'October' UNION SELECT 11, 'November'
+ UNION SELECT 12, 'December'
+ ) months
+ CROSS JOIN departments dept
+ WHERE dept.active = 1
+ ORDER BY dept.department_name, months.month_number;
+ ```
+:::
+
+## Performance & Optimization
+
+:::caution
+**Performance Considerations:**
+
+1. **Result Set Size**: Always calculate expected result size before running
+2. **Memory Usage**: Large cross joins can consume significant memory
+3. **Processing Time**: Exponential growth in processing time with table size
+4. **Network Traffic**: Large result sets increase network overhead
+
+**Optimization Strategies:**
+```sql
+-- Use LIMIT to test queries first
+SELECT p.product_name, c.color_name
+FROM products p
+CROSS JOIN colors c
+LIMIT 100; -- Test with small result set first
+
+-- Use WHERE clauses to reduce combinations
+SELECT p.product_name, c.color_name
+FROM products p
+CROSS JOIN colors c
+WHERE p.category = 'Shirts'
+ AND c.price_adjustment <= 5.00;
+
+-- Consider using EXISTS instead for existence checks
+SELECT p.product_name
+FROM products p
+WHERE EXISTS (
+ SELECT 1 FROM colors c
+ WHERE c.compatible_category = p.category
+);
+```
+:::
+
+## Best Practices & Guidelines
+
+:::info
+**DO's and DON'Ts:**
+
+**DO's:**
+- Calculate result set size before executing
+- Use WHERE clauses to limit combinations
+- Test with LIMIT first
+- Use for legitimate business scenarios (combinations, templates, etc.)
+- Consider alternatives like window functions or recursive CTEs
+
+**DON'Ts:**
+- Use CROSS JOIN when other joins are more appropriate
+- Run unbounded CROSS JOINs on large tables
+- Use for simple data lookup operations
+- Forget to filter results when possible
+
+**Good Practice Example:**
+```sql
+-- Responsible CROSS JOIN usage
+SELECT
+ p.product_name,
+ c.color_name,
+ COUNT(*) OVER() AS total_combinations -- Show total for reference
+FROM products p
+CROSS JOIN colors c
+WHERE p.category = 'Customizable' -- Limit to relevant products
+ AND c.available = 1 -- Only available colors
+ AND p.launch_date <= CURRENT_DATE -- Only launched products
+LIMIT 1000; -- Safety limit
+```
+:::
+
+
+
+## Conclusion
+
+CROSS JOIN is a specialized tool that creates Cartesian products of tables. While powerful for generating combinations and creating comprehensive datasets, it must be used carefully due to its potential for creating extremely large result sets. Understanding when and how to use CROSS JOIN effectively will help you solve complex business problems involving combinations, permutations, and complete data templates.
+
+
\ No newline at end of file
diff --git a/docs/sql/SQL-joins/full-outer-join.md b/docs/sql/SQL-joins/full-outer-join.md
new file mode 100644
index 00000000..c6de6879
--- /dev/null
+++ b/docs/sql/SQL-joins/full-outer-join.md
@@ -0,0 +1,299 @@
+---
+id: full-outer-join
+title: SQL FULL OUTER JOIN #Remember to keep this unique, as it maps with giscus discussions in the recodehive/support/general discussions
+sidebar_label: FULL OUTER JOIN #displays in sidebar
+sidebar_position: 5
+tags:
+ [
+ sql,
+ full outer join,
+ full join,
+ sql full outer join,
+ outer join,
+ join tables,
+ relational database,
+ sql tutorial,
+ ]
+description: Learn about SQL FULL OUTER JOIN, how it works, syntax, examples, and when to use it for including all records from both tables.
+---
+
+SQL **FULL OUTER JOIN** (also known as FULL JOIN) returns all records from both tables, regardless of whether there are matches in the other table. It combines the results of both LEFT JOIN and RIGHT JOIN, showing all records from both tables with NULL values where no matches exist.
+
+:::note
+**Key Characteristics of FULL OUTER JOIN:**
+
+- **Complete Dataset**: Returns every record from both tables, creating a comprehensive view.
+
+- **Union of Results**: Combines LEFT JOIN + RIGHT JOIN behavior in a single operation.
+
+- **NULL Handling**: Shows NULL values for missing matches on either side.
+
+- **Data Completeness**: Ensures no data is lost from either table in the join operation.
+:::
+
+
+ [](https://www.learnsqlonline.org/)
+
+
+:::success
+**When to Use FULL OUTER JOIN:**
+
+- **Data Synchronization**: Comparing data between two systems to find discrepancies
+- **Complete Auditing**: Ensuring all records from both sources are accounted for
+- **Data Migration**: Validating data transfer between old and new systems
+- **Comprehensive Reporting**: Creating reports that need all entities from both tables
+
+**Real-World Example:**
+Comparing customer data between two different systems (CRM and ERP) to identify customers who exist in one system but not the other, ensuring complete data synchronization.
+:::
+
+:::info
+
+## Basic FULL OUTER JOIN Syntax
+
+```sql
+SELECT column1, column2, ...
+FROM table1
+FULL OUTER JOIN table2
+ON table1.column_name = table2.column_name;
+```
+
+| **Component** | **Purpose** | **Example** |
+|---------------|-------------|-------------|
+| SELECT | Choose columns to display | `SELECT c.name, o.order_id` |
+| FROM | First table | `FROM customers c` |
+| FULL OUTER JOIN | Second table | `FULL OUTER JOIN orders o` |
+| ON | Join condition | `ON c.customer_id = o.customer_id` |
+
+## Alternative Syntax
+
+```sql
+-- FULL JOIN (shorthand, same result)
+SELECT c.customer_name, o.order_id
+FROM customers c
+FULL JOIN orders o ON c.customer_id = o.customer_id;
+
+-- Simulating FULL OUTER JOIN with UNION (for databases that don't support it)
+SELECT c.customer_name, o.order_id
+FROM customers c
+LEFT JOIN orders o ON c.customer_id = o.customer_id
+UNION
+SELECT c.customer_name, o.order_id
+FROM customers c
+RIGHT JOIN orders o ON c.customer_id = o.customer_id;
+```
+
+:::
+
+## Practical Examples
+
+
+
+ ```sql
+ -- Get all customers and all orders, showing complete relationship picture
+ SELECT
+ c.customer_id,
+ c.customer_name,
+ c.email,
+ c.registration_date,
+ o.order_id,
+ o.order_date,
+ o.total_amount,
+ CASE
+ WHEN c.customer_id IS NULL THEN 'Orphaned Order'
+ WHEN o.order_id IS NULL THEN 'Customer Without Orders'
+ ELSE 'Active Relationship'
+ END AS relationship_status
+ FROM customers c
+ FULL OUTER JOIN orders o ON c.customer_id = o.customer_id
+ ORDER BY c.customer_name, o.order_date;
+
+ -- Result: All customers AND all orders, with NULLs for non-matches
+ ```
+
+
+ ```sql
+ -- Compare customer data between two systems
+ SELECT
+ COALESCE(crm.customer_id, erp.customer_id) AS customer_id,
+ crm.customer_name AS crm_name,
+ erp.customer_name AS erp_name,
+ crm.email AS crm_email,
+ erp.email AS erp_email,
+ CASE
+ WHEN crm.customer_id IS NULL THEN 'Missing in CRM'
+ WHEN erp.customer_id IS NULL THEN 'Missing in ERP'
+ WHEN crm.email != erp.email THEN 'Email Mismatch'
+ WHEN crm.customer_name != erp.customer_name THEN 'Name Mismatch'
+ ELSE 'Synchronized'
+ END AS sync_status
+ FROM crm_customers crm
+ FULL OUTER JOIN erp_customers erp ON crm.customer_id = erp.customer_id
+ WHERE crm.customer_id IS NULL
+ OR erp.customer_id IS NULL
+ OR crm.email != erp.email
+ OR crm.customer_name != erp.customer_name
+ ORDER BY sync_status, customer_id;
+ ```
+
+
+ ```sql
+ -- Compare current inventory with sales data
+ SELECT
+ COALESCE(inv.product_id, sales.product_id) AS product_id,
+ inv.product_name,
+ inv.current_stock,
+ inv.reorder_level,
+ COALESCE(sales.units_sold, 0) AS units_sold_ytd,
+ COALESCE(sales.revenue, 0) AS revenue_ytd,
+ CASE
+ WHEN inv.product_id IS NULL THEN 'Discontinued Product Still Selling'
+ WHEN sales.product_id IS NULL THEN 'No Sales Activity'
+ WHEN inv.current_stock < inv.reorder_level THEN 'Reorder Needed'
+ WHEN sales.units_sold = 0 THEN 'Slow Moving'
+ ELSE 'Active Product'
+ END AS inventory_status
+ FROM current_inventory inv
+ FULL OUTER JOIN (
+ SELECT
+ oi.product_id,
+ SUM(oi.quantity) AS units_sold,
+ SUM(oi.quantity * oi.unit_price) AS revenue
+ FROM order_items oi
+ JOIN orders o ON oi.order_id = o.order_id
+ WHERE YEAR(o.order_date) = 2024
+ GROUP BY oi.product_id
+ ) sales ON inv.product_id = sales.product_id
+ ORDER BY inventory_status, revenue_ytd DESC;
+ ```
+
+
+ ```sql
+ -- Reconcile transactions between accounting systems
+ SELECT
+ COALESCE(sys1.transaction_id, sys2.transaction_id) AS transaction_id,
+ COALESCE(sys1.transaction_date, sys2.transaction_date) AS transaction_date,
+ sys1.amount AS system1_amount,
+ sys2.amount AS system2_amount,
+ ABS(COALESCE(sys1.amount, 0) - COALESCE(sys2.amount, 0)) AS difference,
+ CASE
+ WHEN sys1.transaction_id IS NULL THEN 'Missing in System 1'
+ WHEN sys2.transaction_id IS NULL THEN 'Missing in System 2'
+ WHEN sys1.amount != sys2.amount THEN 'Amount Discrepancy'
+ ELSE 'Reconciled'
+ END AS reconciliation_status
+ FROM accounting_system1 sys1
+ FULL OUTER JOIN accounting_system2 sys2
+ ON sys1.transaction_id = sys2.transaction_id
+ WHERE sys1.transaction_id IS NULL
+ OR sys2.transaction_id IS NULL
+ OR sys1.amount != sys2.amount
+ ORDER BY reconciliation_status, transaction_date DESC;
+ ```
+
+
+ ```sql
+ -- Complete view of employees and departments
+ SELECT
+ COALESCE(e.employee_id, 'N/A') AS employee_id,
+ e.employee_name,
+ e.position,
+ e.salary,
+ d.department_name,
+ d.location,
+ d.budget,
+ CASE
+ WHEN e.employee_id IS NULL THEN 'Empty Department'
+ WHEN d.department_id IS NULL THEN 'Employee Without Department'
+ ELSE 'Properly Assigned'
+ END AS assignment_status,
+ COUNT(*) OVER (PARTITION BY d.department_id) AS dept_employee_count
+ FROM employees e
+ FULL OUTER JOIN departments d ON e.department_id = d.department_id
+ ORDER BY d.department_name, e.employee_name;
+ ```
+
+
+ ```plaintext
+ -- Sample result showing complete customer-order relationship:
+
+ customer_id | customer_name | email | order_id | order_date | relationship_status
+ ------------|---------------|-------------------|----------|------------|--------------------
+ 1 | John Smith | john@email.com | 101 | 2024-01-15 | Active Relationship
+ 1 | John Smith | john@email.com | 105 | 2024-02-20 | Active Relationship
+ 2 | Jane Doe | jane@email.com | 102 | 2024-01-18 | Active Relationship
+ 3 | Bob Wilson | bob@email.com | NULL | NULL | Customer Without Orders
+ 4 | Alice Brown | alice@email.com | 104 | 2024-02-01 | Active Relationship
+ NULL | NULL | NULL | 999 | 2024-01-10 | Orphaned Order
+
+ -- Note: Shows ALL customers (including Bob with no orders)
+ -- AND all orders (including orphaned order 999 with no customer)
+ ```
+
+
+
+## Database Support & Alternatives
+
+:::warning
+**Database Compatibility:**
+
+Not all databases support FULL OUTER JOIN natively:
+
+- **Supported:** PostgreSQL, SQL Server, Oracle, DB2
+- **Not Supported:** MySQL, SQLite (older versions)
+
+**Alternative for MySQL/SQLite:**
+```sql
+-- Simulate FULL OUTER JOIN using UNION
+SELECT c.customer_id, c.customer_name, o.order_id, o.total_amount
+FROM customers c
+LEFT JOIN orders o ON c.customer_id = o.customer_id
+UNION
+SELECT c.customer_id, c.customer_name, o.order_id, o.total_amount
+FROM customers c
+RIGHT JOIN orders o ON c.customer_id = o.customer_id
+WHERE c.customer_id IS NULL;
+```
+:::
+
+
+## Performance Considerations
+
+:::important
+**FULL OUTER JOIN Performance:**
+
+1. **Resource Intensive**: Requires processing all records from both tables
+2. **Memory Usage**: Can consume significant memory for large datasets
+3. **Index Strategy**: Ensure join columns are properly indexed
+4. **Result Set Size**: Can produce very large result sets
+
+**Optimization Tips:**
+```sql
+-- Use WHERE clauses to limit unnecessary records
+SELECT c.customer_name, o.order_total
+FROM customers c
+FULL OUTER JOIN orders o ON c.customer_id = o.customer_id
+WHERE c.status = 'Active' OR o.order_date >= '2024-01-01';
+
+-- Consider using EXISTS for existence checks instead
+SELECT c.customer_name,
+ CASE WHEN EXISTS (SELECT 1 FROM orders WHERE customer_id = c.customer_id)
+ THEN 'Has Orders' ELSE 'No Orders' END
+FROM customers c;
+```
+:::
+
+## Best Practices
+:::tip
+1. **Use Sparingly**: Only when you truly need all records from both tables
+2. **Handle NULLs Properly**: Use COALESCE, ISNULL, or CASE statements
+3. **Consider Alternatives**: Sometimes UNION ALL might be more efficient
+4. **Test Performance**: Monitor query performance with large datasets
+5. **Document Intent**: Clearly comment why FULL OUTER JOIN is necessary
+:::
+
+## Conclusion
+
+FULL OUTER JOIN is a powerful tool for comprehensive data analysis and ensuring no records are lost when combining datasets. While resource-intensive, it's invaluable for data synchronization, migration validation, and complete reporting scenarios. Use it judiciously and always consider performance implications with large datasets.
+
+
\ No newline at end of file
diff --git a/docs/sql/SQL-joins/inner-join.md b/docs/sql/SQL-joins/inner-join.md
new file mode 100644
index 00000000..f7ff9922
--- /dev/null
+++ b/docs/sql/SQL-joins/inner-join.md
@@ -0,0 +1,246 @@
+---
+id: inner-join
+title: SQL INNER JOIN #Remember to keep this unique, as it maps with giscus discussions in the recodehive/support/general discussions
+sidebar_label: INNER JOIN #displays in sidebar
+sidebar_position: 2
+tags:
+ [
+ sql,
+ inner join,
+ sql inner join,
+ join tables,
+ relational database,
+ sql tutorial,
+ ]
+description: Learn about SQL INNER JOIN, how it works, syntax, examples, and best practices for combining data from multiple tables with matching records.
+---
+
+
+SQL **INNER JOIN** is the most commonly used join operation that returns only the rows that have matching values in both tables. It creates a result set by combining columns from two or more tables based on a related column between them, but only includes records where the join condition is satisfied in both tables.
+
+:::note
+**Key Characteristics of INNER JOIN**:
+
+- **Matching Records Only**: Returns rows only when there are matching values in both tables.
+
+- **Default Join Type**: When you simply write JOIN without specifying the type, it defaults to INNER JOIN.
+
+- **Intersection**: Think of it as the intersection of two datasets - only common elements are included.
+
+- **Performance**: Generally faster than outer joins as it doesn't need to handle NULL values for unmatched records.
+:::
+
+
+ [](https://github.com/sanjay-kv)
+
+
+:::success
+**When to Use INNER JOIN:**
+
+✅ **Finding Related Records**: When you need data that exists in both tables
+✅ **Data Analysis**: Analyzing relationships between entities (customers with orders)
+✅ **Report Generation**: Creating reports with complete, related information
+✅ **Data Validation**: Ensuring referential integrity in your queries
+
+**Real-World Example:**
+Imagine you have a library system with `Books` and `Authors` tables. An INNER JOIN would show you only books that have assigned authors, excluding any orphaned records.
+:::
+
+:::info
+
+## Basic INNER JOIN Syntax
+
+```sql
+SELECT column1, column2, ...
+FROM table1
+INNER JOIN table2
+ON table1.column_name = table2.column_name;
+```
+
+| **Component** | **Purpose** | **Example** |
+|---------------|-------------|-------------|
+| SELECT | Choose columns to display | `SELECT c.name, o.total` |
+| FROM | Primary (left) table | `FROM customers c` |
+| INNER JOIN | Secondary (right) table | `INNER JOIN orders o` |
+| ON | Join condition | `ON c.customer_id = o.customer_id` |
+
+## Alternative Syntax Options
+
+```sql
+-- Using table aliases (recommended)
+SELECT c.name, o.total
+FROM customers c
+INNER JOIN orders o ON c.customer_id = o.customer_id;
+
+-- Without INNER keyword (same result)
+SELECT c.name, o.total
+FROM customers c
+JOIN orders o ON c.customer_id = o.customer_id;
+
+-- Using USING clause (when column names are identical)
+SELECT name, total
+FROM customers
+INNER JOIN orders USING(customer_id);
+```
+
+:::
+
+## Practical Examples
+
+
+
+ ```sql
+ -- Get customers and their orders
+ SELECT
+ c.customer_id,
+ c.customer_name,
+ c.email,
+ o.order_id,
+ o.order_date,
+ o.total_amount
+ FROM customers c
+ INNER JOIN orders o ON c.customer_id = o.customer_id
+ ORDER BY c.customer_name, o.order_date;
+
+ -- Result: Only customers who have placed orders
+ ```
+
+
+ ```sql
+ -- Join three tables: customers, orders, and order_items
+ SELECT
+ c.customer_name,
+ o.order_date,
+ p.product_name,
+ oi.quantity,
+ oi.unit_price,
+ (oi.quantity * oi.unit_price) AS line_total
+ FROM customers c
+ INNER JOIN orders o ON c.customer_id = o.customer_id
+ INNER JOIN order_items oi ON o.order_id = oi.order_id
+ INNER JOIN products p ON oi.product_id = p.product_id
+ WHERE o.order_date >= '2024-01-01'
+ ORDER BY c.customer_name, o.order_date;
+ ```
+
+
+ ```sql
+ -- Get customer order statistics
+ SELECT
+ c.customer_id,
+ c.customer_name,
+ COUNT(o.order_id) AS total_orders,
+ SUM(o.total_amount) AS total_spent,
+ AVG(o.total_amount) AS avg_order_value,
+ MIN(o.order_date) AS first_order,
+ MAX(o.order_date) AS last_order
+ FROM customers c
+ INNER JOIN orders o ON c.customer_id = o.customer_id
+ GROUP BY c.customer_id, c.customer_name
+ HAVING COUNT(o.order_id) > 1
+ ORDER BY total_spent DESC;
+ ```
+
+
+ ```sql
+ -- Join with multiple conditions and filters
+ SELECT
+ e.employee_name,
+ e.department,
+ p.project_name,
+ p.start_date,
+ p.budget
+ FROM employees e
+ INNER JOIN project_assignments pa ON e.employee_id = pa.employee_id
+ INNER JOIN projects p ON pa.project_id = p.project_id
+ WHERE e.department IN ('Engineering', 'Design')
+ AND p.status = 'Active'
+ AND p.budget > 50000
+ AND pa.role = 'Lead'
+ ORDER BY p.start_date DESC;
+ ```
+
+
+ ```sql
+ -- Find employees and their managers (self join)
+ SELECT
+ emp.employee_name AS employee,
+ emp.position AS employee_position,
+ mgr.employee_name AS manager,
+ mgr.position AS manager_position
+ FROM employees emp
+ INNER JOIN employees mgr ON emp.manager_id = mgr.employee_id
+ WHERE emp.department = 'Sales'
+ ORDER BY mgr.employee_name, emp.employee_name;
+ ```
+
+
+ ```plaintext
+ -- Sample result for basic customer-orders join:
+
+ customer_id | customer_name | email | order_id | order_date | total_amount
+ ------------|---------------|-------------------|----------|------------|-------------
+ 1 | John Smith | john@email.com | 101 | 2024-01-15 | 299.99
+ 1 | John Smith | john@email.com | 105 | 2024-02-20 | 149.50
+ 2 | Jane Doe | jane@email.com | 102 | 2024-01-18 | 89.99
+ 3 | Bob Wilson | bob@email.com | 103 | 2024-01-22 | 199.00
+
+ -- Note: Only customers with orders are shown
+ -- Customers without orders are excluded
+ ```
+
+
+
+## Performance Tips & Best Practices
+
+:::tip
+**Optimization Strategies:**
+
+1. **Use Indexes**: Ensure join columns have proper indexes
+ ```sql
+ -- Create indexes on frequently joined columns
+ CREATE INDEX idx_orders_customer_id ON orders(customer_id);
+ CREATE INDEX idx_customers_customer_id ON customers(customer_id);
+ ```
+
+2. **Filter Early**: Apply WHERE conditions before joining when possible
+ ```sql
+ -- Good: Filter before joining
+ SELECT c.name, o.total
+ FROM customers c
+ INNER JOIN (
+ SELECT * FROM orders
+ WHERE order_date >= '2024-01-01'
+ ) o ON c.customer_id = o.customer_id;
+ ```
+
+3. **Select Only Needed Columns**: Don't use SELECT * unnecessarily
+ ```sql
+ -- Good: Specific columns
+ SELECT c.name, o.order_date, o.total
+ FROM customers c
+ INNER JOIN orders o ON c.customer_id = o.customer_id;
+ ```
+
+4. **Use Table Aliases**: Improves readability and performance
+ ```sql
+ -- Clear and concise with aliases
+ SELECT c.name, o.total
+ FROM customers c
+ INNER JOIN orders o ON c.customer_id = o.customer_id;
+ ```
+:::
+
+## Common Use Cases
+
+- **📊 Business Analytics**
+- **📈 Reporting**
+- **🔍 Data Validation**
+- **💼 Business Intelligence**
+
+
+## Conclusion
+
+INNER JOIN is the foundation of relational database querying, allowing you to combine related data from multiple tables efficiently. Master this join type first, as it forms the basis for understanding more complex join operations. Remember that INNER JOIN only returns matching records, making it perfect for analyzing existing relationships in your data.
+
+
\ No newline at end of file
diff --git a/docs/sql/SQL-joins/intro-sql-joins.md b/docs/sql/SQL-joins/intro-sql-joins.md
new file mode 100644
index 00000000..a88273fa
--- /dev/null
+++ b/docs/sql/SQL-joins/intro-sql-joins.md
@@ -0,0 +1,205 @@
+---
+id: intro-sql-joins
+title: Introduction to SQL Joins #Remember to keep this unique, as it maps with giscus discussions in the recodehive/support/general discussions
+sidebar_label: Introduction to SQL Joins #displays in sidebar
+sidebar_position: 1
+tags:
+ [
+ sql,
+ sql joins,
+ inner join,
+ left join,
+ right join,
+ full join,
+ cross join,
+ self join,
+ relational database,
+ ]
+description: In this tutorial, you will learn about SQL Joins, their importance, types of joins, when to use each join type, and how they work with relational databases.
+---
+
+## What are SQL Joins?
+
+SQL **Joins** are operations used to combine rows from two or more tables based on a related column between them. Joins are fundamental to relational databases as they allow you to retrieve data that is spread across multiple tables, following the principles of database normalization.
+
+:::note
+Key Concepts of SQL Joins:
+
+- **Relational Data**: Data is often normalized across multiple tables to reduce redundancy and improve data integrity.
+
+- **Foreign Keys**: Columns that create relationships between tables by referencing primary keys in other tables.
+
+- **Join Conditions**: Criteria that specify how tables should be connected, typically using equality conditions on related columns.
+
+- **Result Sets**: The combined data from multiple tables based on the join operation and conditions specified.
+:::
+
+
+ [](https://www.learnsqlonline.org/)
+
+
+:::success
+**Understanding Table Relationships**
+
+In relational databases, data is organized into separate tables to eliminate redundancy. For example:
+- A **Customers** table stores customer information
+- An **Orders** table stores order details
+- A **Products** table stores product information
+
+Without joins, you'd have to store all customer information in every order record, leading to data duplication and inconsistency. Joins allow you to maintain data integrity while still being able to retrieve comprehensive information across related tables.
+
+> **Normalization** is the process of organizing data to minimize redundancy. This is why we need joins - to bring normalized data back together for meaningful analysis.
+:::
+
+:::info
+
+| **#** | **Join Type** | **Description** |
+|-------|--------------------------------------------------|---------------------------------------------------------------------------------|
+| 1 | `INNER JOIN` | Returns only rows that have matching values in both tables. |
+| 2 | `LEFT JOIN (LEFT OUTER JOIN)` | Returns all rows from the left table and matched rows from the right table. |
+| 3 | `RIGHT JOIN (RIGHT OUTER JOIN)` | Returns all rows from the right table and matched rows from the left table. |
+| 4 | `FULL OUTER JOIN` | Returns all rows when there's a match in either left or right table. |
+| 5 | `CROSS JOIN` | Returns the Cartesian product of both tables (all possible combinations). |
+| 6 | `SELF JOIN` | A table joined with itself to compare rows within the same table. |
+| 7 | `NATURAL JOIN` | Automatically joins tables based on columns with the same name and data type. |
+| 8 | `Join Conditions` | Specify how tables relate using ON or USING clauses. |
+| 9 | `Multiple Table Joins` | Joining more than two tables in a single query. |
+| 10 | `Join Performance` | Understanding indexes and query optimization for efficient joins. |
+
+**Basic Join Syntax Structure:**
+
+| **Component** | **Purpose** | **Example** |
+|---------------|----------------|--------------------|
+| SELECT | Choose columns | SELECT c.name, o.date |
+| FROM | Primary table | FROM customers c |
+| JOIN | Secondary table| JOIN orders o |
+| ON | Join condition | ON c.id = o.customer_id |
+
+:::
+
+ **Here are basic examples of different join types:**
+
+
+
+ ```sql
+ -- INNER JOIN: Get customers and their orders
+ SELECT
+ c.customer_name,
+ c.email,
+ o.order_id,
+ o.order_date,
+ o.total_amount
+ FROM customers c
+ INNER JOIN orders o ON c.customer_id = o.customer_id;
+
+ -- Only returns customers who have placed orders
+ ```
+
+
+ ```sql
+ -- LEFT JOIN: Get all customers and their orders (if any)
+ SELECT
+ c.customer_name,
+ c.email,
+ o.order_id,
+ o.order_date,
+ o.total_amount
+ FROM customers c
+ LEFT JOIN orders o ON c.customer_id = o.customer_id;
+
+ -- Returns all customers, even those without orders (NULL values for order columns)
+ ```
+
+
+ ```sql
+ -- RIGHT JOIN: Get all orders and their customers
+ SELECT
+ c.customer_name,
+ c.email,
+ o.order_id,
+ o.order_date,
+ o.total_amount
+ FROM customers c
+ RIGHT JOIN orders o ON c.customer_id = o.customer_id;
+
+ -- Returns all orders, even if customer data is missing
+ ```
+
+
+ ```sql
+ -- FULL OUTER JOIN: Get all customers and all orders
+ SELECT
+ c.customer_name,
+ c.email,
+ o.order_id,
+ o.order_date,
+ o.total_amount
+ FROM customers c
+ FULL OUTER JOIN orders o ON c.customer_id = o.customer_id;
+
+ -- Returns all records from both tables, with NULLs where no match exists
+ ```
+
+
+ ```sql
+ -- CROSS JOIN: Cartesian product of two tables
+ SELECT
+ p.product_name,
+ c.category_name
+ FROM products p
+ CROSS JOIN categories c;
+
+ -- Returns every product paired with every category
+ -- Use carefully as it can return very large result sets!
+ ```
+
+
+ ```sql
+ -- SELF JOIN: Find employees and their managers
+ SELECT
+ e1.employee_name AS employee,
+ e1.position,
+ e2.employee_name AS manager
+ FROM employees e1
+ LEFT JOIN employees e2 ON e1.manager_id = e2.employee_id;
+
+ -- Joins the employees table with itself
+ ```
+
+
+
+**Join Best Practices:**
+
+1. **Always use table aliases** for readability when joining multiple tables
+2. **Specify join conditions explicitly** using the ON clause
+3. **Use appropriate indexes** on columns used in join conditions for better performance
+4. **Consider the data volume** and choose the most efficient join type
+5. **Test with sample data** to ensure joins return expected results
+
+:::
+
+## 🔗 Why Learn SQL Joins?
+
+**SQL Joins** are essential for working with **normalized relational databases** where data is logically separated across multiple tables. Understanding joins allows you to:
+
+### 📊 Essential Skills for Data Professionals
+
+**1. ✅ Data Retrieval Across Tables**
+Combine related information from multiple tables to create comprehensive reports and analyses.
+
+**2. ✅ Maintain Data Integrity**
+Work with properly normalized databases that eliminate data redundancy while still accessing complete information.
+
+**3. ✅ Advanced Analytics**
+Perform complex queries that analyze relationships between different entities in your database.
+
+**4. ✅ Report Generation**
+Create meaningful business reports that require data from multiple sources.
+
+---
+
+### Conclusion
+
+Mastering SQL joins is crucial for anyone working with relational databases. They enable you to leverage the full power of normalized database design while still being able to retrieve comprehensive, meaningful data for analysis and reporting. Understanding when and how to use each type of join will significantly enhance your ability to work with real-world database systems.
+
+
\ No newline at end of file
diff --git a/docs/sql/SQL-joins/left-join.md b/docs/sql/SQL-joins/left-join.md
new file mode 100644
index 00000000..b4d1c4c3
--- /dev/null
+++ b/docs/sql/SQL-joins/left-join.md
@@ -0,0 +1,306 @@
+---
+id: left-join
+title: SQL LEFT JOIN (LEFT OUTER JOIN) #Remember to keep this unique, as it maps with giscus discussions in the recodehive/support/general discussions
+sidebar_label: LEFT JOIN #displays in sidebar
+sidebar_position: 3
+tags:
+ [
+ sql,
+ left join,
+ left outer join,
+ sql left join,
+ outer join,
+ join tables
+ ]
+description: Learn about SQL LEFT JOIN (LEFT OUTER JOIN), how it works, syntax, examples, and when to use it for including all records from the left table.
+---
+
+
+SQL **LEFT JOIN** (also known as LEFT OUTER JOIN) returns all records from the left (first) table and the matched records from the right (second) table. If there are no matches in the right table, the result will contain NULL values for all columns from the right table.
+
+:::note
+**Key Characteristics of LEFT JOIN:**
+
+- **All Left Records**: Returns every record from the left table, regardless of matches.
+
+- **Matching Right Records**: Includes matched records from the right table when available.
+
+- **NULL for Unmatched**: Shows NULL values for right table columns when no match exists.
+
+- **Preservation**: Preserves the completeness of the primary (left) table data.
+:::
+
+
+ [](https://github.com/sanjay-kv)
+
+
+:::success
+**When to Use LEFT JOIN:**
+
+✅ **Finding Missing Relationships**: Customers without orders, students without grades
+✅ **Complete Data Analysis**: When you need all records from the primary table
+✅ **Optional Information**: Including supplementary data that may not exist for all records
+✅ **Data Auditing**: Identifying gaps in related data
+
+**Real-World Example:**
+In an e-commerce system, you want to see all customers and their orders (if any). LEFT JOIN ensures you see customers who haven't placed orders yet, with NULL values in the order columns.
+:::
+
+:::info
+
+## Basic LEFT JOIN Syntax
+
+```sql
+SELECT column1, column2, ...
+FROM table1
+LEFT JOIN table2
+ON table1.column_name = table2.column_name;
+```
+
+| **Component** | **Purpose** | **Example** |
+|---------------|-------------|-------------|
+| SELECT | Choose columns to display | `SELECT c.name, o.total` |
+| FROM | Primary (left) table | `FROM customers c` |
+| LEFT JOIN | Secondary (right) table | `LEFT JOIN orders o` |
+| ON | Join condition | `ON c.customer_id = o.customer_id` |
+
+## Alternative Syntax
+
+```sql
+-- LEFT OUTER JOIN (same as LEFT JOIN)
+SELECT c.name, o.total
+FROM customers c
+LEFT OUTER JOIN orders o ON c.customer_id = o.customer_id;
+
+-- With table aliases (recommended)
+SELECT c.name, COALESCE(o.total, 0) as order_total
+FROM customers c
+LEFT JOIN orders o ON c.customer_id = o.customer_id;
+```
+
+:::
+
+## Practical Examples
+
+
+
+ ```sql
+ -- Get all customers and their orders (including customers with no orders)
+ SELECT
+ c.customer_id,
+ c.customer_name,
+ c.email,
+ c.registration_date,
+ o.order_id,
+ o.order_date,
+ o.total_amount
+ FROM customers c
+ LEFT JOIN orders o ON c.customer_id = o.customer_id
+ ORDER BY c.customer_name, o.order_date;
+
+ -- Result: All customers, with NULL values for customers without orders
+ ```
+
+
+ ```sql
+ -- Find customers who haven't placed any orders
+ SELECT
+ c.customer_id,
+ c.customer_name,
+ c.email,
+ c.registration_date,
+ 'No orders placed' AS status
+ FROM customers c
+ LEFT JOIN orders o ON c.customer_id = o.customer_id
+ WHERE o.order_id IS NULL
+ ORDER BY c.registration_date DESC;
+
+ -- Useful for marketing campaigns targeting inactive customers
+ ```
+
+
+ ```sql
+ -- Get customer statistics including those with zero orders
+ SELECT
+ c.customer_id,
+ c.customer_name,
+ c.registration_date,
+ COUNT(o.order_id) AS total_orders,
+ COALESCE(SUM(o.total_amount), 0) AS total_spent,
+ CASE
+ WHEN COUNT(o.order_id) = 0 THEN 'Inactive'
+ WHEN COUNT(o.order_id) < 3 THEN 'Low Activity'
+ ELSE 'Active'
+ END AS customer_segment
+ FROM customers c
+ LEFT JOIN orders o ON c.customer_id = o.customer_id
+ GROUP BY c.customer_id, c.customer_name, c.registration_date
+ ORDER BY total_spent DESC;
+ ```
+
+
+ ```sql
+ -- Get complete customer profile with optional data
+ SELECT
+ c.customer_name,
+ c.email,
+ a.street_address,
+ a.city,
+ a.country,
+ p.phone_number,
+ COUNT(o.order_id) AS order_count,
+ MAX(o.order_date) AS last_order_date
+ FROM customers c
+ LEFT JOIN addresses a ON c.customer_id = a.customer_id
+ LEFT JOIN phone_numbers p ON c.customer_id = p.customer_id
+ LEFT JOIN orders o ON c.customer_id = o.customer_id
+ GROUP BY c.customer_id, c.customer_name, c.email,
+ a.street_address, a.city, a.country, p.phone_number
+ ORDER BY c.customer_name;
+ ```
+
+
+ ```sql
+ -- Analyze customer activity over specific periods
+ SELECT
+ c.customer_name,
+ c.registration_date,
+ COUNT(o.order_id) AS orders_this_year,
+ COALESCE(SUM(o.total_amount), 0) AS revenue_this_year,
+ CASE
+ WHEN MAX(o.order_date) >= DATE_SUB(CURRENT_DATE, INTERVAL 30 DAY)
+ THEN 'Recently Active'
+ WHEN MAX(o.order_date) IS NOT NULL
+ THEN 'Previously Active'
+ ELSE 'Never Purchased'
+ END AS activity_status
+ FROM customers c
+ LEFT JOIN orders o ON c.customer_id = o.customer_id
+ AND o.order_date >= '2024-01-01'
+ WHERE c.registration_date >= '2023-01-01'
+ GROUP BY c.customer_id, c.customer_name, c.registration_date
+ ORDER BY revenue_this_year DESC;
+ ```
+
+
+ ```plaintext
+ -- Sample result showing all customers including those without orders:
+
+ customer_id | customer_name | email | order_id | order_date | total_amount
+ ------------|---------------|-------------------|----------|------------|-------------
+ 1 | John Smith | john@email.com | 101 | 2024-01-15 | 299.99
+ 1 | John Smith | john@email.com | 105 | 2024-02-20 | 149.50
+ 2 | Jane Doe | jane@email.com | 102 | 2024-01-18 | 89.99
+ 3 | Bob Wilson | bob@email.com | NULL | NULL | NULL
+ 4 | Alice Brown | alice@email.com | 104 | 2024-02-01 | 199.00
+ 5 | Mike Davis | mike@email.com | NULL | NULL | NULL
+
+ -- Note: Bob Wilson and Mike Davis have no orders (NULL values)
+ -- But they still appear in the result set
+ ```
+
+
+
+## Handling NULL Values
+
+:::tip
+**Working with NULLs in LEFT JOIN:**
+
+1. **Use CASE Statements for Complex Logic**:
+ ```sql
+ SELECT
+ c.customer_name,
+ CASE
+ WHEN o.order_id IS NULL THEN 'No orders'
+ WHEN o.total_amount > 1000 THEN 'High value customer'
+ ELSE 'Regular customer'
+ END AS customer_type
+ FROM customers c
+ LEFT JOIN orders o ON c.customer_id = o.customer_id;
+ ```
+2. **Filter for NULL or NOT NULL**:
+ ```sql
+ -- Customers without orders
+ SELECT c.* FROM customers c
+ LEFT JOIN orders o ON c.customer_id = o.customer_id
+ WHERE o.order_id IS NULL;
+
+ -- Customers with orders
+ SELECT c.* FROM customers c
+ LEFT JOIN orders o ON c.customer_id = o.customer_id
+ WHERE o.order_id IS NOT NULL;
+ ```
+:::
+
+## Common Use Cases & Business Applications
+
+**📊 Customer Analysis**
+```sql
+-- Customer segmentation based on purchase behavior
+SELECT
+ CASE
+ WHEN COUNT(o.order_id) = 0 THEN 'New/Inactive'
+ WHEN SUM(o.total_amount) > 5000 THEN 'VIP'
+ WHEN COUNT(o.order_id) > 10 THEN 'Frequent'
+ ELSE 'Regular'
+ END AS segment,
+ COUNT(*) AS customer_count
+FROM customers c
+LEFT JOIN orders o ON c.customer_id = o.customer_id
+GROUP BY segment;
+```
+
+**📈 Performance Reporting**
+```sql
+-- Monthly sales report including all months
+SELECT
+ m.month_name,
+ COALESCE(SUM(s.sales_amount), 0) AS total_sales,
+ COUNT(s.sale_id) AS transaction_count
+FROM months_reference m
+LEFT JOIN sales s ON m.month_number = MONTH(s.sale_date)
+ AND YEAR(s.sale_date) = 2024
+GROUP BY m.month_number, m.month_name
+ORDER BY m.month_number;
+```
+
+**🎯 Marketing Insights**
+```sql
+-- Email campaign effectiveness
+SELECT
+ c.customer_segment,
+ COUNT(c.customer_id) AS total_customers,
+ COUNT(r.response_id) AS responses,
+ ROUND(COUNT(r.response_id) * 100.0 / COUNT(c.customer_id), 2) AS response_rate
+FROM customers c
+LEFT JOIN campaign_responses r ON c.customer_id = r.customer_id
+ AND r.campaign_id = 'SPRING2024'
+GROUP BY c.customer_segment;
+```
+
+## Performance Considerations
+
+:::tip
+**LEFT JOIN Performance Tips:**
+
+1. **Index Join Columns**: Ensure both tables have indexes on join columns
+2. **Limit Result Sets**: Use WHERE clauses to filter the left table when possible
+3. **Consider EXISTS**: For existence checks, sometimes EXISTS is more efficient than LEFT JOIN
+4. **Avoid SELECT \***: Only select columns you need to reduce memory usage
+5. **Filter NULLs Early**: If you don't need unmatched records, consider using INNER JOIN instead
+
+```sql
+-- More efficient: Filter left table first
+SELECT c.name, o.total
+FROM customers c
+LEFT JOIN orders o ON c.customer_id = o.customer_id
+WHERE c.status = 'Active' -- Filter before joining
+ AND c.registration_date >= '2023-01-01';
+```
+:::
+
+## Conclusion
+
+LEFT JOIN is essential for comprehensive data analysis where you need to preserve all records from your primary table while including related information when available. It's particularly valuable for identifying gaps in data, customer analysis, and creating complete reports that account for all entities, not just those with relationships.
+
+
\ No newline at end of file
diff --git a/docs/sql/SQL-joins/right-join.md b/docs/sql/SQL-joins/right-join.md
new file mode 100644
index 00000000..91b72f98
--- /dev/null
+++ b/docs/sql/SQL-joins/right-join.md
@@ -0,0 +1,292 @@
+---
+id: right-join
+title: SQL RIGHT JOIN (RIGHT OUTER JOIN) #Remember to keep this unique, as it maps with giscus discussions in the recodehive/support/general discussions
+sidebar_label: RIGHT JOIN #displays in sidebar
+sidebar_position: 4
+tags:
+ [
+ sql,
+ right join,
+ right outer join,
+ sql right join,
+ outer join,
+ ]
+description: Learn about SQL RIGHT JOIN (RIGHT OUTER JOIN), how it works, syntax, examples, and when to use it for including all records from the right table.
+---
+
+SQL **RIGHT JOIN** (also known as RIGHT OUTER JOIN) returns all records from the right (second) table and the matched records from the left (first) table. If there are no matches in the left table, the result will contain NULL values for all columns from the left table.
+
+:::note
+**Key Characteristics of RIGHT JOIN:**
+
+- **All Right Records**: Returns every record from the right table, regardless of matches.
+
+- **Matching Left Records**: Includes matched records from the left table when available.
+
+- **NULL for Unmatched**: Shows NULL values for left table columns when no match exists.
+
+- **Less Common**: Used less frequently than LEFT JOIN but serves specific use cases.
+:::
+
+
+ [](https://www.learnsqlonline.org/)
+
+
+:::success
+**When to Use RIGHT JOIN:**
+
+- **Reference Data Completeness**: Ensuring all lookup/reference table entries are represented
+- **Inventory Analysis**: All products shown, even those without sales
+- **Data Validation**: Finding orphaned records in child tables
+- **Complete Catalogs**: All categories/departments shown regardless of content
+
+**Real-World Example:**
+In a retail system, you want to see all products in your catalog and their sales data (if any). RIGHT JOIN on products ensures every product appears, even those with zero sales.
+:::
+
+:::info
+
+## Basic RIGHT JOIN Syntax
+
+```sql
+SELECT column1, column2, ...
+FROM table1
+RIGHT JOIN table2
+ON table1.column_name = table2.column_name;
+```
+
+| **Component** | **Purpose** | **Example** |
+|---------------|-------------|-------------|
+| SELECT | Choose columns to display | `SELECT o.order_id, c.name` |
+| FROM | Primary (left) table | `FROM orders o` |
+| RIGHT JOIN | Secondary (right) table | `RIGHT JOIN customers c` |
+| ON | Join condition | `ON o.customer_id = c.customer_id` |
+
+## Alternative Syntax
+
+```sql
+-- RIGHT OUTER JOIN (same as RIGHT JOIN)
+SELECT o.order_id, c.customer_name
+FROM orders o
+RIGHT OUTER JOIN customers c ON o.customer_id = c.customer_id;
+
+-- Equivalent LEFT JOIN (often preferred for readability)
+SELECT o.order_id, c.customer_name
+FROM customers c
+LEFT JOIN orders o ON c.customer_id = o.customer_id;
+```
+
+:::
+
+## Practical Examples
+
+
+
+ ```sql
+ -- Get all products and their order details (including products never ordered)
+ SELECT
+ p.product_id,
+ p.product_name,
+ p.price,
+ p.category,
+ oi.order_item_id,
+ oi.quantity,
+ oi.unit_price,
+ o.order_date
+ FROM order_items oi
+ INNER JOIN orders o ON oi.order_id = o.order_id
+ RIGHT JOIN products p ON oi.product_id = p.product_id
+ ORDER BY p.product_name;
+
+ -- Result: All products, with NULL values for products never ordered
+ ```
+
+
+ ```sql
+ -- Find products that have never been sold
+ SELECT
+ p.product_id,
+ p.product_name,
+ p.price,
+ p.stock_quantity,
+ 'Never sold' AS sales_status
+ FROM order_items oi
+ RIGHT JOIN products p ON oi.product_id = p.product_id
+ WHERE oi.product_id IS NULL
+ ORDER BY p.price DESC;
+
+ -- Useful for inventory management and discontinuation decisions
+ ```
+
+
+ ```sql
+ -- Analyze all product categories and their performance
+ SELECT
+ c.category_id,
+ c.category_name,
+ c.description,
+ COUNT(p.product_id) AS total_products,
+ COUNT(oi.order_item_id) AS items_sold,
+ COALESCE(SUM(oi.quantity * oi.unit_price), 0) AS total_revenue,
+ CASE
+ WHEN COUNT(oi.order_item_id) = 0 THEN 'No Sales'
+ WHEN SUM(oi.quantity * oi.unit_price) > 10000 THEN 'High Performance'
+ ELSE 'Moderate Performance'
+ END AS performance_level
+ FROM products p
+ LEFT JOIN order_items oi ON p.product_id = oi.product_id
+ RIGHT JOIN categories c ON p.category_id = c.category_id
+ GROUP BY c.category_id, c.category_name, c.description
+ ORDER BY total_revenue DESC;
+ ```
+
+
+ ```sql
+ -- Show all departments and their employee counts
+ SELECT
+ d.department_id,
+ d.department_name,
+ d.location,
+ d.budget,
+ COUNT(e.employee_id) AS employee_count,
+ COALESCE(AVG(e.salary), 0) AS avg_salary,
+ CASE
+ WHEN COUNT(e.employee_id) = 0 THEN 'Vacant Department'
+ WHEN COUNT(e.employee_id) < 5 THEN 'Small Team'
+ ELSE 'Large Team'
+ END AS team_size
+ FROM employees e
+ RIGHT JOIN departments d ON e.department_id = d.department_id
+ GROUP BY d.department_id, d.department_name, d.location, d.budget
+ ORDER BY employee_count DESC;
+ ```
+
+
+ ```sql
+ -- Complete monthly sales report (all months shown)
+ SELECT
+ m.month_number,
+ m.month_name,
+ m.quarter,
+ COUNT(o.order_id) AS total_orders,
+ COALESCE(SUM(o.total_amount), 0) AS monthly_revenue,
+ COUNT(DISTINCT o.customer_id) AS unique_customers
+ FROM orders o
+ RIGHT JOIN (
+ SELECT 1 as month_number, 'January' as month_name, 'Q1' as quarter
+ UNION SELECT 2, 'February', 'Q1'
+ UNION SELECT 3, 'March', 'Q1'
+ UNION SELECT 4, 'April', 'Q2'
+ UNION SELECT 5, 'May', 'Q2'
+ UNION SELECT 6, 'June', 'Q2'
+ UNION SELECT 7, 'July', 'Q3'
+ UNION SELECT 8, 'August', 'Q3'
+ UNION SELECT 9, 'September', 'Q3'
+ UNION SELECT 10, 'October', 'Q4'
+ UNION SELECT 11, 'November', 'Q4'
+ UNION SELECT 12, 'December', 'Q4'
+ ) m ON MONTH(o.order_date) = m.month_number
+ AND YEAR(o.order_date) = 2024
+ GROUP BY m.month_number, m.month_name, m.quarter
+ ORDER BY m.month_number;
+ ```
+
+
+ ```plaintext
+ -- Sample result showing all products including those never ordered:
+
+ product_id | product_name | price | order_item_id | quantity | unit_price | order_date
+ -----------|-----------------|--------|---------------|----------|------------|------------
+ 1 | Laptop Pro | 1299.99| 1 | 2 | 1299.99 | 2024-01-15
+ 1 | Laptop Pro | 1299.99| 5 | 1 | 1299.99 | 2024-02-20
+ 2 | Wireless Mouse | 29.99 | 2 | 3 | 29.99 | 2024-01-18
+ 3 | USB Cable | 9.99 | NULL | NULL | NULL | NULL
+ 4 | Monitor 4K | 399.99 | 3 | 1 | 399.99 | 2024-01-22
+ 5 | Keyboard Mech | 149.99 | NULL | NULL | NULL | NULL
+
+ -- Note: USB Cable and Keyboard Mech were never ordered (NULL values)
+ -- But they still appear because we used RIGHT JOIN on products
+ ```
+
+
+
+## RIGHT JOIN vs LEFT JOIN
+
+:::tip
+**Understanding the Difference:**
+
+**RIGHT JOIN** and **LEFT JOIN** are mirror operations. The choice between them is often a matter of preference and query readability:
+
+```sql
+-- These queries produce identical results:
+
+-- RIGHT JOIN approach
+SELECT p.product_name, o.order_date
+FROM orders o
+RIGHT JOIN products p ON o.product_id = p.product_id;
+
+-- LEFT JOIN approach (more commonly used)
+SELECT p.product_name, o.order_date
+FROM products p
+LEFT JOIN orders o ON p.product_id = o.product_id;
+```
+
+:::
+
+:::important
+**RIGHT JOIN Performance Notes:**
+
+1. **Index Strategy**: Ensure the right table (which will be fully scanned) has appropriate indexes
+2. **Query Planning**: Database optimizers may convert RIGHT JOIN to LEFT JOIN internally
+3. **Readability**: Consider using LEFT JOIN for better code maintainability
+4. **Table Size**: Be mindful when the right table is significantly larger
+
+```sql
+-- Performance tip: Use WHERE clause to limit right table when possible
+SELECT p.product_name, o.order_date
+FROM orders o
+RIGHT JOIN products p ON o.product_id = p.product_id
+WHERE p.status = 'Active' -- Filter right table to improve performance
+ AND p.created_date >= '2023-01-01';
+```
+:::
+
+## When NOT to Use RIGHT JOIN
+
+**Avoid RIGHT JOIN when:**
+- LEFT JOIN would be more readable
+- You're joining more than 2-3 tables
+- The query logic becomes confusing
+- Team conventions prefer LEFT JOIN
+
+**Use RIGHT JOIN when:**
+- You specifically need all records from the second table
+- It makes the business logic clearer
+- Working with reference/lookup tables as the primary focus
+
+## Best Practices
+
+1. **Document Intent**: Comment why RIGHT JOIN is chosen over LEFT JOIN
+2. **Consistent Style**: Stick to team conventions (most prefer LEFT JOIN)
+3. **Test Thoroughly**: Ensure NULL handling works as expected
+4. **Consider Alternatives**: Sometimes UNION or EXISTS might be clearer
+
+```sql
+-- Good: Clear intent and proper NULL handling
+SELECT
+ p.product_name,
+ COALESCE(sales_summary.revenue, 0) as total_revenue,
+ CASE
+ WHEN sales_summary.revenue IS NULL THEN 'No Sales'
+ ELSE 'Has Sales'
+ END as sales_status
+FROM sales_summary
+RIGHT JOIN products p ON sales_summary.product_id = p.product_id
+WHERE p.status = 'Active';
+```
+
+## Conclusion
+
+RIGHT JOIN is a powerful tool for ensuring completeness from the perspective of the second table in your query. While less commonly used than LEFT JOIN, it serves specific use cases well, particularly in inventory management, performance reporting, and reference data analysis. Understanding when and how to use RIGHT JOIN effectively will make you a more versatile SQL developer.
+
+
\ No newline at end of file
diff --git a/docs/sql/SQL-joins/self-join.md b/docs/sql/SQL-joins/self-join.md
new file mode 100644
index 00000000..05e8b36a
--- /dev/null
+++ b/docs/sql/SQL-joins/self-join.md
@@ -0,0 +1,313 @@
+---
+id: self-join
+title: SQL SELF JOIN #Remember to keep this unique, as it maps with giscus discussions in the recodehive/support/general discussions
+sidebar_label: SELF JOIN #displays in sidebar
+sidebar_position: 7
+tags:
+ [
+ sql,
+ self join,
+ sql self join,
+ hierarchical data,
+ recursive queries,
+ join tables,
+ relational database,
+ sql tutorial,
+ database queries,
+ ]
+description: Learn about SQL SELF JOIN, how to join a table with itself, syntax, examples, and use cases for hierarchical data and comparing rows within the same table.
+---
+
+## What is SELF JOIN?
+
+SQL **SELF JOIN** is a technique where a table is joined with itself to compare rows within the same table or to work with hierarchical data structures. This is accomplished by treating the same table as if it were two separate tables using different table aliases.
+
+:::note
+Key Characteristics of SELF JOIN:
+**Same Table**: Joins a table with itself using different aliases.
+
+**Hierarchical Data**: Perfect for parent-child relationships within a single table.
+
+**Row Comparison**: Enables comparison between different rows in the same table.
+
+**Flexible Join Types**: Can be INNER, LEFT, RIGHT, or FULL OUTER self joins.
+:::
+
+
+ [](https://github.com/sanjay-kv)
+
+
+:::success
+**When to Use SELF JOIN:**
+
+✅ **Hierarchical Structures**: Employee-manager relationships, organizational charts
+✅ **Comparing Rows**: Finding duplicates, comparing values within the same table
+✅ **Sequential Data**: Analyzing consecutive records or time-series data
+✅ **Graph Relationships**: Social networks, recommendation systems
+✅ **Parent-Child Data**: Category trees, menu structures, geographical hierarchies
+
+**Real-World Example:**
+An employee table where each employee has a manager_id pointing to another employee in the same table. SELF JOIN helps you retrieve employee names along with their manager names.
+:::
+
+:::info
+
+## Basic SELF JOIN Syntax
+
+```sql
+SELECT columns
+FROM table_name alias1
+JOIN table_name alias2
+ON alias1.column = alias2.column;
+```
+
+| **Component** | **Purpose** | **Example** |
+|---------------|-------------|-------------|
+| SELECT | Choose columns from both aliases | `SELECT e1.name, e2.name AS manager` |
+| FROM | First reference to table | `FROM employees e1` |
+| JOIN | Second reference to same table | `JOIN employees e2` |
+| ON | Join condition | `ON e1.manager_id = e2.employee_id` |
+
+## Table Alias Requirements
+
+```sql
+-- Wrong: No aliases (causes ambiguity)
+SELECT name, name
+FROM employees
+JOIN employees ON manager_id = employee_id;
+
+-- Correct: Using aliases to distinguish references
+SELECT e1.name AS employee, e2.name AS manager
+FROM employees e1
+JOIN employees e2 ON e1.manager_id = e2.employee_id;
+```
+
+:::
+
+## Practical Examples
+
+
+
+ ```sql
+ -- Get employees and their managers
+ SELECT
+ e1.employee_id,
+ e1.employee_name AS employee,
+ e1.position AS employee_position,
+ e1.salary AS employee_salary,
+ e2.employee_id AS manager_id,
+ e2.employee_name AS manager,
+ e2.position AS manager_position,
+ e1.hire_date,
+ DATEDIFF(CURRENT_DATE, e1.hire_date) AS days_employed
+ FROM employees e1
+ LEFT JOIN employees e2 ON e1.manager_id = e2.employee_id
+ WHERE e1.status = 'Active'
+ ORDER BY e2.employee_name, e1.employee_name;
+
+ -- LEFT JOIN ensures we see employees without managers (CEO, etc.)
+ ```
+
+
+ ```sql
+ -- Find duplicate customer records based on email
+ SELECT
+ c1.customer_id AS customer1_id,
+ c1.customer_name AS customer1_name,
+ c1.email,
+ c1.registration_date AS reg_date1,
+ c2.customer_id AS customer2_id,
+ c2.customer_name AS customer2_name,
+ c2.registration_date AS reg_date2,
+ ABS(DATEDIFF(c1.registration_date, c2.registration_date)) AS days_apart
+ FROM customers c1
+ INNER JOIN customers c2
+ ON c1.email = c2.email
+ AND c1.customer_id < c2.customer_id -- Avoid duplicate pairs
+ WHERE c1.email IS NOT NULL
+ AND c1.email != ''
+ ORDER BY c1.email, c1.registration_date;
+ ```
+
+
+ ```sql
+ -- Compare consecutive sales records to find trends
+ SELECT
+ s1.sale_date AS current_date,
+ s1.daily_sales AS current_sales,
+ s2.sale_date AS previous_date,
+ s2.daily_sales AS previous_sales,
+ (s1.daily_sales - s2.daily_sales) AS sales_change,
+ ROUND(((s1.daily_sales - s2.daily_sales) / s2.daily_sales) * 100, 2) AS percent_change,
+ CASE
+ WHEN s1.daily_sales > s2.daily_sales THEN 'Increase'
+ WHEN s1.daily_sales < s2.daily_sales THEN 'Decrease'
+ ELSE 'No Change'
+ END AS trend
+ FROM daily_sales s1
+ INNER JOIN daily_sales s2
+ ON s1.sale_date = DATE_ADD(s2.sale_date, INTERVAL 1 DAY)
+ WHERE s1.sale_date >= '2024-01-02' -- Skip first date (no previous)
+ ORDER BY s1.sale_date;
+ ```
+
+
+ ```sql
+ -- Find products frequently bought together
+ SELECT
+ p1.product_name AS product1,
+ p2.product_name AS product2,
+ COUNT(*) AS times_bought_together,
+ AVG(oi1.unit_price) AS avg_price_product1,
+ AVG(oi2.unit_price) AS avg_price_product2,
+ COUNT(DISTINCT oi1.order_id) AS total_orders
+ FROM order_items oi1
+ INNER JOIN order_items oi2
+ ON oi1.order_id = oi2.order_id
+ AND oi1.product_id < oi2.product_id -- Avoid duplicate pairs
+ INNER JOIN products p1 ON oi1.product_id = p1.product_id
+ INNER JOIN products p2 ON oi2.product_id = p2.product_id
+ WHERE oi1.product_id != oi2.product_id
+ GROUP BY oi1.product_id, oi2.product_id, p1.product_name, p2.product_name
+ HAVING COUNT(*) >= 5 -- At least 5 co-purchases
+ ORDER BY times_bought_together DESC, p1.product_name;
+ ```
+
+
+ ```sql
+ -- Create location hierarchy (Country -> State -> City)
+ SELECT
+ city.location_name AS city,
+ city.population AS city_population,
+ state.location_name AS state,
+ country.location_name AS country,
+ country.population AS country_population,
+ CONCAT(city.location_name, ', ', state.location_name, ', ', country.location_name) AS full_address
+ FROM locations city
+ LEFT JOIN locations state ON city.parent_location_id = state.location_id
+ LEFT JOIN locations country ON state.parent_location_id = country.location_id
+ WHERE city.location_type = 'City'
+ AND city.active = 1
+ ORDER BY country.location_name, state.location_name, city.location_name;
+ ```
+
+
+ ```plaintext
+ -- Sample result for employee-manager relationship:
+
+ employee_id | employee | employee_position | manager_id | manager | manager_position
+ ------------|---------------|-------------------|------------|---------------|------------------
+ 101 | Alice Johnson | Software Engineer | 201 | Bob Smith | Engineering Manager
+ 102 | Carol Davis | Software Engineer | 201 | Bob Smith | Engineering Manager
+ 103 | David Wilson | QA Tester | 202 | Eve Brown | QA Manager
+ 201 | Bob Smith | Engineering Mgr | 301 | Frank Taylor | VP Engineering
+ 202 | Eve Brown | QA Manager | 301 | Frank Taylor | VP Engineering
+ 301 | Frank Taylor | VP Engineering | NULL | NULL | NULL
+
+ -- Note: Frank Taylor has NULL manager (top of hierarchy)
+ -- Multiple employees can report to the same manager
+ ```
+
+
+
+
+
+## Performance Considerations
+
+:::tip
+**SELF JOIN Performance Tips:**
+
+1. **Proper Indexing**: Ensure columns used in join conditions are indexed
+ ```sql
+ -- Essential indexes for employee hierarchy
+ CREATE INDEX idx_employees_manager_id ON employees(manager_id);
+ CREATE INDEX idx_employees_employee_id ON employees(employee_id);
+ ```
+
+2. **Limit Recursive Depth**: Prevent infinite loops in hierarchical queries
+ ```sql
+ -- Add level limit to recursive queries
+ WHERE level <= 5 -- Maximum 5 levels deep
+ ```
+
+3. **Filter Early**: Use WHERE clauses to reduce dataset size
+ ```sql
+ -- Filter before joining for better performance
+ FROM employees e1
+ JOIN employees e2 ON e1.manager_id = e2.employee_id
+ WHERE e1.status = 'Active' AND e2.status = 'Active';
+ ```
+
+4. **Use EXISTS for Existence Checks**:
+ ```sql
+ -- More efficient for checking if employee has subordinates
+ SELECT employee_name,
+ EXISTS(SELECT 1 FROM employees e2 WHERE e2.manager_id = e1.employee_id) AS is_manager
+ FROM employees e1;
+ ```
+
+5. **Avoid Cartesian Products**:
+ ```sql
+ -- Bad: Missing join condition creates Cartesian product
+ SELECT e1.name, e2.name FROM employees e1, employees e2;
+
+ -- Good: Proper join condition
+ SELECT e1.name, e2.name
+ FROM employees e1
+ JOIN employees e2 ON e1.manager_id = e2.employee_id;
+ ```
+:::
+
+
+
+## Best Practices Summary
+
+:::info
+**SELF JOIN Best Practices:**
+
+**✅ Essential Guidelines:**
+
+1. **Always Use Table Aliases**: Required to distinguish table references
+2. **Proper Join Conditions**: Ensure meaningful relationships between rows
+3. **Handle NULLs Appropriately**: Use LEFT JOIN for optional relationships
+4. **Index Join Columns**: Critical for performance with large tables
+5. **Limit Result Sets**: Use WHERE clauses and LIMIT when testing
+6. **Document Complex Logic**: Comment hierarchical and recursive queries
+7. **Test Edge Cases**: Verify behavior with NULL values and missing relationships
+
+**🔧 Performance Optimization:**
+```sql
+-- Example of well-optimized SELF JOIN
+SELECT
+ emp.employee_name AS employee,
+ mgr.employee_name AS manager,
+ emp.department
+FROM employees emp
+LEFT JOIN employees mgr ON emp.manager_id = mgr.employee_id
+WHERE emp.status = 'Active' -- Filter early
+ AND emp.hire_date >= '2020-01-01' -- Limit scope
+ AND (mgr.status = 'Active' OR mgr.status IS NULL) -- Handle NULLs
+ORDER BY emp.department, mgr.employee_name, emp.employee_name
+LIMIT 1000; -- Reasonable limit for testing
+```
+
+**📝 Documentation Example:**
+```sql
+/*
+Purpose: Generate employee hierarchy report showing direct reporting relationships
+Business Logic:
+- Shows all active employees and their direct managers
+- Includes employees without managers (CEO level)
+- Orders by department then hierarchy
+Performance: Uses indexes on employee_id and manager_id columns
+*/
+```
+:::
+
+
+
+## Conclusion
+
+SELF JOIN is a powerful technique for analyzing relationships within a single table. Whether you're working with hierarchical organizational data, comparing sequential records, finding duplicates, or analyzing peer relationships, mastering SELF JOIN will significantly enhance your ability to extract meaningful insights from your data. Remember to always use proper aliases, handle NULL values appropriately, and optimize for performance with appropriate indexing and filtering.
+
+
\ No newline at end of file
diff --git a/sidebars.ts b/sidebars.ts
index b4f3a7c6..2eaf05fb 100644
--- a/sidebars.ts
+++ b/sidebars.ts
@@ -113,6 +113,20 @@ const sidebars: SidebarsConfig = {
'sql/table-transformation/list-drop-table',
],
},
+ {
+ type: 'category',
+ label: 'SQL Joins',
+ className: 'custom-sidebar-sql-joins',
+ items: [
+ 'sql/SQL-joins/intro-sql-joins',
+ 'sql/SQL-joins/inner-join',
+ 'sql/SQL-joins/left-join',
+ 'sql/SQL-joins/right-join',
+ 'sql/SQL-joins/full-outer-join',
+ 'sql/SQL-joins/cross-join',
+ 'sql/SQL-joins/self-join',
+ ],
+ },
],
},
{
@@ -144,8 +158,7 @@ const sidebars: SidebarsConfig = {
'Technical/intro-github',
],
},
-
],
};
-export default sidebars;
+export default sidebars;
\ No newline at end of file