Why stored procedures centralize logic in MySQL - Performance Analysis

Time Complexity: Why stored procedures centralize logic

O(n)

Understanding Time Complexity

When we use stored procedures, we want to know how the time to run them changes as data grows.

We ask: How does the work inside a stored procedure scale with input size?

Scenario Under Consideration

Analyze the time complexity of this stored procedure that sums values from a table.

CREATE PROCEDURE SumValues()
BEGIN
  DECLARE total INT DEFAULT 0;
  DECLARE done BOOLEAN DEFAULT FALSE;
  DECLARE val INT;
  DECLARE cur CURSOR FOR SELECT value FROM numbers;
  DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

  OPEN cur;
  read_loop: LOOP
    FETCH cur INTO val;
    IF done THEN
      LEAVE read_loop;
    END IF;
    SET total = total + val;
  END LOOP;
  CLOSE cur;
  SELECT total;
END;
    

This procedure reads all rows from the 'numbers' table and sums their values.

Identify Repeating Operations

Look for repeated actions inside the procedure.

• Primary operation: Looping through each row in the 'numbers' table.
• How many times: Once for every row in the table.

How Execution Grows With Input

The procedure does one addition per row, so more rows mean more additions.

Input Size (n)	Approx. Operations
10	10 additions
100	100 additions
1000	1000 additions

Pattern observation: The work grows directly with the number of rows.

Final Time Complexity

Time Complexity: O(n)

This means the time to run grows in a straight line with the number of rows processed.

Common Mistake

[X] Wrong: "Stored procedures always run instantly no matter data size."

[OK] Correct: Stored procedures still do work on data, so bigger data means more time.

Interview Connect

Understanding how stored procedures scale helps you explain how database logic handles growing data smoothly.

Self-Check

"What if the stored procedure called another procedure inside the loop? How would that affect time complexity?"

Practice

1. Why do stored procedures help centralize logic in a MySQL database?

easy

A. Because they speed up the network connection

B. Because they automatically create database backups

C. Because they replace the need for tables

D. Because they keep all related SQL code in one place for reuse and maintenance

Solution

1. Step 1: Understand the role of stored procedures

   Stored procedures contain SQL code that can be executed repeatedly without rewriting it.

2. Step 2: Recognize centralization benefits

   By placing logic inside stored procedures, all applications use the same code, making maintenance easier and consistent.

3. Final Answer:

   Because they keep all related SQL code in one place for reuse and maintenance -> Option D

4. Quick Check:

   Centralizing logic = reuse and maintenance [OK]

Hint: Stored procedures group SQL logic centrally for easy reuse [OK]

Common Mistakes:

• Thinking stored procedures create backups
• Confusing stored procedures with tables
• Assuming stored procedures affect network speed

2. Which of the following is the correct syntax to create a stored procedure named GetUser in MySQL?

easy

A. CREATE PROCEDURE GetUser BEGIN SELECT * FROM users END

B. CREATE PROCEDURE GetUser() BEGIN SELECT * FROM users; END;

C. CREATE FUNCTION GetUser() SELECT * FROM users;

D. CREATE PROCEDURE GetUser() { SELECT * FROM users; }

Solution

1. Step 1: Recall MySQL stored procedure syntax

   Stored procedures use CREATE PROCEDURE name() BEGIN ... END; with semicolons inside.

2. Step 2: Check each option

   CREATE PROCEDURE GetUser() BEGIN SELECT * FROM users; END; uses correct syntax with BEGIN and END and semicolons; others miss BEGIN/END or use wrong keywords or braces.

3. Final Answer:

   CREATE PROCEDURE GetUser() BEGIN SELECT * FROM users; END; -> Option B

4. Quick Check:

   Correct syntax includes BEGIN...END with semicolons [OK]

Hint: Stored procedures need BEGIN and END blocks with semicolons [OK]

Common Mistakes:

• Using CREATE FUNCTION instead of PROCEDURE
• Omitting BEGIN and END
• Using curly braces instead of BEGIN/END

3. Given the stored procedure:

CREATE PROCEDURE GetCount()
BEGIN
  SELECT COUNT(*) AS total FROM orders;
END;

What will be the output when calling CALL GetCount(); if the orders table has 5 rows?

medium

A. A result set with one row and column 'total' showing 5

B. An error because no parameters are passed

C. No output because SELECT inside procedure does not return data

D. A result set with 5 rows showing order details

Solution

1. Step 1: Understand what the procedure does

   The procedure runs SELECT COUNT(*) from orders, which returns one row with the count.

2. Step 2: Predict output of CALL

   Calling the procedure returns the SELECT result as a result set with one row and column named 'total' showing 5.

3. Final Answer:

   A result set with one row and column 'total' showing 5 -> Option A

4. Quick Check:

   COUNT(*) returns number of rows = 5 [OK]

Hint: CALL runs procedure and returns SELECT results as output [OK]

Common Mistakes:

• Thinking SELECT inside procedure does not return data
• Confusing COUNT(*) with row details
• Expecting error due to no parameters

4. Consider this stored procedure code:

CREATE PROCEDURE UpdateStock()
BEGIN
  UPDATE products SET stock = stock - 1 WHERE id = 10
END;

What is the error in this code?

medium

A. Using UPDATE inside a procedure is not allowed

B. Incorrect procedure name syntax

C. Missing semicolon after UPDATE statement

D. Missing parentheses after procedure name

Solution

1. Step 1: Check syntax inside BEGIN...END

   Each statement inside BEGIN...END must end with a semicolon in MySQL.

2. Step 2: Identify missing semicolon

   The UPDATE line lacks a semicolon at the end, causing a syntax error.

3. Final Answer:

   Missing semicolon after UPDATE statement -> Option C

4. Quick Check:

   Statements inside BEGIN...END need semicolons [OK]

Hint: Always end statements inside procedures with semicolons [OK]

Common Mistakes:

• Forgetting semicolon after SQL statements
• Thinking procedure name syntax is wrong
• Believing UPDATE is disallowed in procedures

5. A company wants to ensure all applications update customer balances the same way. Which benefit of stored procedures best supports this goal?

hard

A. Stored procedures centralize logic to ensure consistent data handling

B. Stored procedures improve network speed for updates

C. Stored procedures automatically create audit logs

D. Stored procedures allow direct table access without permissions

Solution

1. Step 1: Understand the goal

   The company wants consistent updates to customer balances across all applications.

2. Step 2: Identify stored procedure benefit

   Centralizing update logic in stored procedures ensures all apps use the same code, preventing inconsistencies.

3. Final Answer:

   Stored procedures centralize logic to ensure consistent data handling -> Option A

4. Quick Check:

   Centralized logic = consistent data updates [OK]

Hint: Centralize update logic to keep data consistent across apps [OK]

Common Mistakes:

• Assuming stored procedures speed up network
• Thinking they auto-create audit logs
• Believing stored procedures bypass permissions