diff --git a/docs/sql/SQL-Advance/sql-procedures-functions-triggers.md b/docs/sql/SQL-Advance/sql-procedures-functions-triggers.md new file mode 100644 index 00000000..c645f778 --- /dev/null +++ b/docs/sql/SQL-Advance/sql-procedures-functions-triggers.md @@ -0,0 +1,426 @@ +--- +id: sql-procedures-functions-triggers +title: SQL Stored Procedures, Functions, and Triggers +sidebar_label: Procedures, Functions, Triggers +sidebar_position: 6 +tags: [sql, stored-procedures, functions, triggers, database, relational-databases] +description: In this super beginner-friendly guide, you’ll dive deep into SQL stored procedures, functions, and triggers—powerful tools to automate, reuse, and manage database operations with detailed explanations! +keywords: [sql, stored procedures, functions, triggers, sql tutorial, sql basics, database management, sql for beginners, sql in 2025] +--- + +## 📙 Welcome to Stored Procedures, Functions, and Triggers! + +Hey there, SQL learner! Stored procedures, functions, and triggers are like the Swiss Army knife of databases, helping you automate tasks, reuse code, and react to data changes. They’re essential for building efficient, maintainable, and automated database systems. Think of stored procedures as reusable scripts, functions as custom calculators, and triggers as automatic responders to database events. We’ll use a simple `students` table (with columns `id`, `name`, `age`, `marks`, and `city`) to walk through each concept with clear examples. Let’s dive in with detailed explanations to make you a pro! + +### 📘 What Are Stored Procedures, Functions, and Triggers? + +These are database objects that enhance how you interact with your database: +- **Stored Procedures**: Pre-written SQL scripts stored in the database, reusable with parameters, for tasks like inserting data or generating reports. +- **User-defined Functions (UDFs)**: Custom functions that return a single value (scalar), a table from a single query (inline), or a complex table (table-valued) for use in SQL statements. +- **Triggers**: Automated procedures that run before, after, or instead of specific events (INSERT, UPDATE, DELETE) to enforce rules, log changes, or handle complex operations. + +Each serves a unique purpose, and understanding their differences is key to using them effectively. Stored procedures are great for complex operations, functions for reusable calculations, and triggers for automatic actions tied to data changes. + +> **Pro Tip**: These tools can save time and improve performance, but use them wisely to avoid overcomplicating your database logic! + +### 📘 Stored Procedures (Reusable Blocks with Parameters!) + +Stored procedures are like pre-packaged SQL programs stored in the database. They allow you to bundle multiple SQL statements into a single, reusable unit that can accept input parameters (e.g., a student’s ID or marks) and return output parameters (e.g., a status message). They’re ideal for tasks like data validation, batch updates, or generating reports, as they reduce repetitive coding, improve performance by minimizing network traffic, and enhance security by controlling access to logic. + +**Detailed Explanation**: +- **Purpose**: Stored procedures encapsulate business logic (e.g., inserting a student record after validation) so you don’t have to rewrite SQL queries repeatedly. They’re executed on the database server, reducing the need to send large queries over a network. +- **Parameters**: + - **Input Parameters**: Pass values to customize behavior (e.g., a student’s name). + - **Output Parameters**: Return results to the caller (e.g., success status). + - **Optional Parameters**: Supported in DBMS like SQL Server with default values. +- **Execution**: Use `CALL` (MySQL, PostgreSQL) or `EXECUTE` (SQL Server) to invoke them. +- **Components**: + - Can include conditional logic (IF/ELSE), loops, error handling (TRY/CATCH in SQL Server), and transactions. + - Support complex operations like joining tables, updating multiple records, or calling other procedures. +- **Benefits**: + - **Reusability**: Write once, use multiple times across applications. + - **Performance**: Pre-compiled in many DBMS (e.g., SQL Server), reducing execution time. + - **Security**: Users can execute procedures without direct table access, reducing risk. + - **Maintainability**: Update logic in one place without changing application code. +- **Use Cases**: + - Inserting records with validation (e.g., checking for duplicate IDs). + - Generating reports by joining multiple tables. + - Performing batch updates (e.g., updating marks for all students in a city). +- **Syntax Variations**: + - MySQL requires `DELIMITER` to define procedures due to semicolon conflicts. + - SQL Server uses `CREATE PROCEDURE` with optional `WITH ENCRYPTION` for security. + - PostgreSQL supports PL/pgSQL for advanced logic, including loops and exception handling. +- **As of 2025**: Modern DBMS like SQL Server 2025 and PostgreSQL 17 offer enhanced features, such as JSON integration for dynamic outputs, AI-driven logic for predictive tasks, and improved performance for parameterized queries. + +**Examples**: + :::info + + +```sql title="Creating a Stored Procedure with Input and Output Parameters" +DELIMITER // +CREATE PROCEDURE AddStudent( + IN p_id INT, + IN p_name VARCHAR(50), + IN p_age INT, + IN p_marks INT, + IN p_city VARCHAR(50), + OUT p_status VARCHAR(100) +) +BEGIN + DECLARE existing_id INT; + -- Check for duplicate ID + SELECT COUNT(*) INTO existing_id FROM students WHERE id = p_id; + IF existing_id > 0 THEN + SET p_status = 'Error: Student ID already exists'; + ELSEIF p_marks < 0 THEN + SET p_status = 'Error: Marks cannot be negative'; + ELSE + INSERT INTO students (id, name, age, marks, city) + VALUES (p_id, p_name, p_age, p_marks, p_city); + SET p_status = 'Student added successfully'; + END IF; +END // +DELIMITER ; +``` + + + +Stored procedure `AddStudent` created successfully. + + + +```sql title="Calling the Stored Procedure" +CALL AddStudent(1, 'Alice', 20, 85, 'Mumbai', @status); +SELECT @status AS result; +``` + + + +| result | +|---------------------------| +| Student added successfully | + + +::: + +> **What NOT to Do**: +> - Don’t create overly complex procedures with dozens of statements—they’re hard to debug and maintain. +> - Don’t forget to set the DELIMITER in MySQL (e.g., `//`) when defining procedures, or you’ll get syntax errors. +> - Don’t skip error handling; always validate inputs (e.g., check for duplicate IDs) to prevent data issues. +> - Don’t grant execute permissions to users who don’t need access to the procedure’s logic. +> - Don’t ignore transaction control (e.g., START TRANSACTION, COMMIT) in procedures that modify data to ensure consistency. + +### 🔄 User-defined Functions (Scalar, Inline, Table-valued!) + +User-defined functions (UDFs) are custom functions you create to perform calculations or return data for use in SQL queries. Unlike stored procedures, functions always return a value (scalar or table) and are typically used within SELECT, WHERE, or JOIN clauses. They come in three types: scalar (returns a single value), inline table-valued (returns a table from a single SELECT), and multi-statement table-valued (returns a table with complex logic). + +**Detailed Explanation**: +- **Scalar Functions**: + - Return a single value (e.g., a letter grade based on marks). + - Used like built-in functions (e.g., `UPPER()`, `COUNT()`) in SELECT or WHERE clauses. + - Must be **DETERMINISTIC** (same input, same output) in many DBMS for use in indexes or persisted columns. + - Example: Converting a numeric mark to a letter grade (A, B, C, D). + - Performance: Can be slow if called for every row in large datasets. +- **Inline Table-valued Functions**: + - Return a table result from a single SELECT statement, similar to a parameterized view. + - Optimized by the DBMS, as the SELECT is inlined into the calling query’s execution plan. + - Example: Retrieving students from a specific city. + - Ideal for simple filtering or joins without complex logic. +- **Multi-statement Table-valued Functions**: + - Return a table built with multiple SQL statements (e.g., loops, temporary tables). + - More flexible but less optimized than inline functions due to procedural logic. + - Example: Selecting top students with additional calculations (e.g., grades). + - Supported in SQL Server with `@table` syntax; MySQL has limited support. +- **Benefits**: + - **Reusability**: Use the same function across multiple queries. + - **Modularity**: Encapsulate calculations for cleaner queries. + - **Flexibility**: Table-valued functions can be used in JOINs or as subqueries. +- **Limitations**: + - Cannot modify data (e.g., INSERT, UPDATE) in most DBMS, unlike procedures. + - Scalar functions can impact performance in large queries due to row-by-row execution. + - Not all DBMS support all types (e.g., MySQL lacks multi-statement table-valued functions). +- **Syntax Variations**: + - SQL Server uses `CREATE FUNCTION` with specific syntax for each type. + - MySQL requires `DELIMITER` and supports scalar and inline functions. + - PostgreSQL uses PL/pgSQL for advanced logic and supports all types. +- **As of 2025**: DBMS like SQL Server 2025 and PostgreSQL 17 improve function performance with better inlining, support for JSON outputs, and integration with AI-driven analytics for dynamic calculations. + +**Examples**: + :::info + + +```sql title="Creating a Scalar Function for Grading" +DELIMITER // +CREATE FUNCTION GetGrade(p_marks INT) RETURNS CHAR(1) +DETERMINISTIC +BEGIN + DECLARE grade CHAR(1); + IF p_marks >= 90 THEN + SET grade = 'A'; + ELSEIF p_marks >= 80 THEN + SET grade = 'B'; + ELSEIF p_marks >= 70 THEN + SET grade = 'C'; + ELSE + SET grade = 'D'; + END IF; + RETURN grade; +END // +DELIMITER ; +``` + + + +Function `GetGrade` created successfully. + + + +```sql title="Using Scalar Function in a Query" +SELECT name, marks, GetGrade(marks) AS grade +FROM students; +``` + + + +| name | marks | grade | +|-------|-------|-------| +| Alice | 85 | B | +| Bob | 92 | A | +| Carol | 75 | C | + + + +```sql title="Creating an Inline Table-valued Function" +CREATE FUNCTION GetStudentsByCity(p_city VARCHAR(50)) +RETURNS TABLE +AS +RETURN ( + SELECT id, name, marks, city + FROM students + WHERE city = p_city +); +``` + + + +Function `GetStudentsByCity` created successfully. + + + +```sql title="Using Inline Table-valued Function" +SELECT * FROM GetStudentsByCity('Mumbai'); +``` + + + +| id | name | marks | city | +|----|-------|-------|--------| +| 1 | Alice | 85 | Mumbai | + + + +```sql title="Creating a Multi-statement Table-valued Function" +CREATE FUNCTION GetTopStudents(p_min_marks INT) +RETURNS @result TABLE (id INT, name VARCHAR(50), marks INT, grade CHAR(1)) +AS +BEGIN + INSERT INTO @result + SELECT id, name, marks, GetGrade(marks) + FROM students + WHERE marks > p_min_marks; + RETURN; +END; +``` + + + +Function `GetTopStudents` created successfully. + + + +```sql title="Using Multi-statement Table-valued Function" +SELECT * FROM GetTopStudents(80); +``` + + + +| id | name | marks | grade | +|----|-------|-------|-------| +| 1 | Alice | 85 | B | +| 2 | Bob | 92 | A | + + +::: + +> **What NOT to Do**: +> - Don’t mark a function as DETERMINISTIC if it uses non-deterministic operations (e.g., RAND(), NOW())—it can cause inconsistent results or errors. +> - Don’t overuse scalar functions in WHERE clauses for large datasets—they execute row-by-row and can slow queries. +> - Don’t create complex table-valued functions when a simple view or inline function would suffice. +> - Don’t assume all DBMS support multi-statement table-valued functions (e.g., MySQL doesn’t). +> - Don’t forget to test functions with edge cases (e.g., null inputs) to ensure robustness. + +### 📘 Triggers (Automatic Actions on Events!) + +Triggers are special stored procedures that automatically execute in response to specific database events (INSERT, UPDATE, DELETE) on a table or view. They’re ideal for enforcing business rules (e.g., preventing negative marks), logging changes, or handling operations on views. Triggers can be **BEFORE** (run before the event), **AFTER** (run after the event), or **INSTEAD OF** (replace the event, typically for views). + +**Detailed Explanation**: +- **Types**: + - **BEFORE Triggers**: + - Execute before the event (INSERT, UPDATE, DELETE). + - Can modify the `NEW` row (for INSERT/UPDATE) or validate data. + - Use Case: Set default values or prevent invalid data (e.g., negative marks). + - Example: Ensuring student age is at least 15 before insertion. + - **AFTER Triggers**: + - Execute after the event completes successfully. + - Access `OLD` (original row) and `NEW` (updated/inserted row) values. + - Use Case: Log changes to an audit table or update related tables. + - Example: Recording mark changes in a log table. + - **INSTEAD OF Triggers**: + - Replace the event entirely, commonly used with views to handle operations that aren’t directly possible (e.g., inserting into a view that joins multiple tables). + - Use Case: Redirect INSERT on a view to update underlying tables. + - Example: Inserting into a view combining `students` and `courses`. + - Supported in SQL Server, PostgreSQL, Oracle; not in MySQL. +- **Scope**: + - **FOR EACH ROW**: Executes for each affected row (most common). + - **FOR EACH STATEMENT**: Executes once per event (supported in PostgreSQL, Oracle). +- **Key Terms**: + - `NEW`: The new row being inserted or updated. + - `OLD`: The original row before an update or delete. + - `INSERTED`/`DELETED`: SQL Server terms for `NEW`/`OLD` in triggers. +- **Use Cases**: + - **Validation**: Prevent invalid data (e.g., negative marks). + - **Auditing**: Log changes to a separate table. + - **Synchronization**: Update related tables (e.g., summary tables). + - **View Operations**: Enable DML (INSERT/UPDATE/DELETE) on complex views. +- **Benefits**: + - **Automation**: No need to call logic manually for every change. + - **Consistency**: Enforce rules at the database level, not application. + - **Flexibility**: Handle complex logic tied to data changes. +- **Limitations**: + - Cannot return results to the caller (unlike functions). + - Can cause performance issues if overused or recursive. + - Debugging is challenging due to automatic execution. + - INSTEAD OF triggers are not supported in all DBMS (e.g., MySQL). +- **Syntax Variations**: + - MySQL uses `DELIMITER` and supports only BEFORE/AFTER triggers. + - SQL Server uses `CREATE TRIGGER` with `INSERTED`/`DELETED` tables. + - PostgreSQL supports PL/pgSQL and all trigger types, including FOR EACH STATEMENT. +- **As of 2025**: DBMS like SQL Server 2025 and PostgreSQL 17 enhance trigger performance with optimized execution plans, support for JSON logging, and integration with temporal tables for automatic history tracking. + +**Examples**: + :::info + + +```sql title="Creating a BEFORE Trigger for Validation" +DELIMITER // +CREATE TRIGGER BeforeStudentInsert +BEFORE INSERT ON students +FOR EACH ROW +BEGIN + IF NEW.marks < 0 THEN + SET NEW.marks = 0; -- Prevent negative marks + END IF; + IF NEW.age < 15 THEN + SIGNAL SQLSTATE '45000' + SET MESSAGE_TEXT = 'Error: Student age must be at least 15'; + END IF; +END // +DELIMITER ; +``` + + + +Trigger `BeforeStudentInsert` created successfully. + + + +```sql title="Testing BEFORE Trigger" +INSERT INTO students (id, name, age, marks, city) +VALUES (3, 'Carol', 19, -5, 'Delhi'); +``` + + + +1 row inserted; marks set to 0. + + + +```sql title="Creating an AFTER Trigger for Logging" +DELIMITER // +CREATE TRIGGER AfterStudentUpdate +AFTER UPDATE ON students +FOR EACH ROW +BEGIN + INSERT INTO student_log (student_id, old_marks, new_marks, change_time) + VALUES (OLD.id, OLD.marks, NEW.marks, NOW()); -- Assume student_log table +END // +DELIMITER ; +``` + + + +Trigger `AfterStudentUpdate` created successfully. + + + +```sql title="Testing AFTER Trigger" +UPDATE students SET marks = 90 WHERE id = 1; +``` + + + +1 row updated; log entry added to `student_log`. + + + +```sql title="Creating an INSTEAD OF Trigger for a View" +-- Assume a view combining students and courses +CREATE VIEW student_course_view AS +SELECT s.id, s.name, s.marks, c.course_name +FROM students s +JOIN courses c ON s.id = c.student_id; + +CREATE TRIGGER InsteadOfInsertStudentCourse +INSTEAD OF INSERT ON student_course_view +FOR EACH ROW +BEGIN + INSERT INTO students (id, name, marks) + VALUES (NEW.id, NEW.name, NEW.marks); + INSERT INTO courses (student_id, course_name) + VALUES (NEW.id, NEW.course_name); +END; +``` + + + +Trigger `InsteadOfInsertStudentCourse` created successfully. + + + +```sql title="Testing INSTEAD OF Trigger" +INSERT INTO student_course_view (id, name, marks, course_name) +VALUES (4, 'Dave', 80, 'Math'); +``` + + + +1 row inserted into `students` and `courses` via view. + + +::: + +> **What NOT to Do**: +> - Don’t create triggers that update the same table they’re triggered on—it can cause recursive loops or errors. +> - Don’t overuse triggers for logic better handled in application code or stored procedures—they’re harder to debug. +> - Don’t ignore performance; triggers run for every affected row, which can slow large operations. +> - Don’t use INSTEAD OF triggers in MySQL, as they’re not supported; use BEFORE/AFTER or application logic instead. +> - Don’t skip testing triggers with edge cases (e.g., null values, bulk operations) to avoid unexpected behavior. + +## ✅ What You’ve Learned + +You’re now a master of SQL stored procedures, functions, and triggers! You’ve deeply explored: +- **Stored Procedures**: Reusable SQL blocks with input/output parameters for complex tasks like data insertion or reporting, with benefits like performance, security, and maintainability. +- **User-defined Functions**: Scalar functions for single-value calculations, inline table-valued functions for simple table results, and multi-statement table-valued functions for complex table logic. +- **Triggers**: BEFORE triggers for validation, AFTER triggers for logging, and INSTEAD OF triggers for handling view operations, tied to INSERT, UPDATE, or DELETE events. + +Practice these with the `students` table to automate and streamline your database tasks. Follow the “What NOT to Do” tips to keep your code clean, efficient, and error-free! \ No newline at end of file diff --git a/sidebars.ts b/sidebars.ts index 3a967d15..2f6f93b9 100644 --- a/sidebars.ts +++ b/sidebars.ts @@ -77,8 +77,8 @@ const sidebars: SidebarsConfig = { "GitHub/Fun-Profile-Customizations/Anurag-Hazra's-GitHub-Readme-Cards", "GitHub/Fun-Profile-Customizations/Trophy-Case-Streaks", "GitHub/Fun-Profile-Customizations/Snake-Contribution-Animation", - ] - } + ], + }, ], }, { @@ -127,7 +127,7 @@ const sidebars: SidebarsConfig = { "sql/SQL-basics/sql-datatypes", "sql/SQL-basics/primary-key-foreign-key", "sql/SQL-basics/sql-operators", - "sql/SQL-basics/sql-clauses" + "sql/SQL-basics/sql-clauses", ], }, { @@ -164,6 +164,7 @@ const sidebars: SidebarsConfig = { "sql/SQL-Advance/common-table-expressions", "sql/SQL-Advance/window-functions", "sql/SQL-Advance/sql-indexes", + "sql/SQL-Advance/sql-procedures-functions-triggers", ], }, ],