User-defined functions in SQL - Time & Space Complexity

Time Complexity: User-defined functions

O(n)

Understanding Time Complexity

When we use user-defined functions in SQL, it is important to know how their execution time changes as the data grows.

We want to understand how the function's running time scales with input size.

Scenario Under Consideration

Analyze the time complexity of the following SQL user-defined function and its usage.

CREATE FUNCTION GetDiscount(price DECIMAL) RETURNS DECIMAL LANGUAGE plpgsql AS $$
BEGIN
  IF price > 100 THEN
    RETURN price * 0.1;
  ELSE
    RETURN price * 0.05;
  END IF;
END;
$$;

SELECT product_id, GetDiscount(price) FROM products;
    

This function calculates a discount based on price and is called for each product in the products table.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: The function GetDiscount is called once for each row in the products table.
• How many times: The number of times equals the number of rows in products, say n.

How Execution Grows With Input

As the number of products grows, the total work grows proportionally because the function runs once per product.

Input Size (n)	Approx. Operations
10	10 function calls
100	100 function calls
1000	1000 function calls

Pattern observation: The total execution time grows linearly with the number of rows.

Final Time Complexity

Time Complexity: O(n)

This means the total time grows directly in proportion to the number of rows processed.

Common Mistake

[X] Wrong: "The function runs just once, so its time does not depend on the number of rows."

[OK] Correct: The function is called for each row, so total time adds up with more rows.

Interview Connect

Understanding how user-defined functions affect query time helps you write efficient database code and explain performance clearly.

Self-Check

"What if the function called another function inside it that also runs in constant time? How would the overall time complexity change?"

Practice

1. What is the main purpose of a user-defined function in SQL?

easy

A. To create reusable code that returns a single value

B. To store large amounts of data

C. To create tables automatically

D. To delete records from a table

Solution

1. Step 1: Understand what user-defined functions do

   User-defined functions are designed to perform specific tasks and return a single value.

2. Step 2: Compare options with the function's purpose

   Only To create reusable code that returns a single value describes creating reusable code that returns a single value, which matches the function's role.

3. Final Answer:

   To create reusable code that returns a single value -> Option A

4. Quick Check:

   User-defined function = reusable single-value code [OK]

Hint: Functions return one value and reuse code easily [OK]

Common Mistakes:

• Confusing functions with tables or data storage
• Thinking functions delete or modify data directly
• Assuming functions return multiple rows or tables

2. Which of the following is the correct way to start creating a scalar user-defined function in SQL?

easy

A. DROP FUNCTION function_name();

B. CREATE FUNCTION function_name() RETURNS INT AS BEGIN RETURN 1; END;

C. SELECT FUNCTION function_name();

D. CREATE TABLE function_name();

Solution

1. Step 1: Identify the correct syntax for creating a function

   The correct syntax starts with CREATE FUNCTION, specifies the return type, and includes a BEGIN...END block.

2. Step 2: Check each option's validity

   CREATE FUNCTION function_name() RETURNS INT AS BEGIN RETURN 1; END; matches the correct syntax. Options A, B, and C are for other SQL commands (dropping, table creation, and selection).

3. Final Answer:

   CREATE FUNCTION function_name() RETURNS INT AS BEGIN RETURN 1; END; -> Option B

4. Quick Check:

   CREATE FUNCTION + RETURNS + BEGIN...END = correct syntax [OK]

Hint: Functions start with CREATE FUNCTION and specify RETURNS [OK]

Common Mistakes:

• Using CREATE TABLE instead of CREATE FUNCTION
• Trying to SELECT a function directly without calling it
• Confusing DROP FUNCTION with creation syntax

3. Given the function below, what will be the output of SELECT dbo.AddFive(10);?

CREATE FUNCTION dbo.AddFive(@num INT) RETURNS INT AS BEGIN RETURN @num + 5; END;

medium

A. 5

B. 10

C. 15

D. Syntax Error

Solution

1. Step 1: Understand the function logic

   The function takes an integer input and returns the input plus 5.

2. Step 2: Calculate the output for input 10

   10 + 5 = 15, so the function returns 15.

3. Final Answer:

   15 -> Option C

4. Quick Check:

   Input 10 + 5 = 15 [OK]

Hint: Add input to 5 as function returns input + 5 [OK]

Common Mistakes:

• Confusing input and output values
• Assuming function returns input unchanged
• Expecting syntax error due to missing parameters

4. Identify the error in the following user-defined function:

CREATE FUNCTION dbo.MultiplyByTwo(@val INT)
RETURNS INT
BEGIN
  SET @val = @val * 2;
  RETURN @val;
END;

medium

A. Missing AS keyword before BEGIN

B. Functions cannot modify input parameters

C. RETURN statement is not allowed in functions

D. Function must return VARCHAR, not INT

Solution

1. Step 1: Review function syntax rules

   In SQL, the AS keyword is required before the BEGIN block in function definitions.

2. Step 2: Check the given function

   The function is missing AS before BEGIN, causing a syntax error.

3. Final Answer:

   Missing AS keyword before BEGIN -> Option A

4. Quick Check:

   CREATE FUNCTION ... RETURNS ... AS BEGIN ... [OK]

Hint: Always include AS before BEGIN in function syntax [OK]

Common Mistakes:

• Trying to modify input parameters inside functions
• Omitting AS keyword before BEGIN
• Confusing function return types

5. You want to create a user-defined function that returns the length of a string only if the string is not empty; otherwise, it returns 0. Which of the following function definitions correctly implements this logic?

hard

A. CREATE FUNCTION dbo.StringLength(@input VARCHAR(100)) RETURNS INT AS BEGIN RETURN NULL; END;

B. CREATE FUNCTION dbo.StringLength(@input VARCHAR(100)) RETURNS INT AS BEGIN IF @input = '' RETURN 1; ELSE RETURN LEN(@input); END;

C. CREATE FUNCTION dbo.StringLength(@input VARCHAR(100)) RETURNS INT AS BEGIN RETURN CASE WHEN @input = '' THEN 1 ELSE LEN(@input) END; END;

D. CREATE FUNCTION dbo.StringLength(@input VARCHAR(100)) RETURNS INT AS BEGIN RETURN LEN(@input); END;

Solution

1. Step 1: Understand the requirement

   The function must return 0 if the string is empty, otherwise return its length.

2. Step 2: Analyze each option

   CREATE FUNCTION dbo.StringLength(@input VARCHAR(100)) RETURNS INT AS BEGIN RETURN LEN(@input); END; correctly returns LEN(@input), and since LEN('')=0 it satisfies the logic. CREATE FUNCTION dbo.StringLength(@input VARCHAR(100)) RETURNS INT AS BEGIN IF @input = '' RETURN 1; ELSE RETURN LEN(@input); END; returns 1 for empty strings, incorrect. CREATE FUNCTION dbo.StringLength(@input VARCHAR(100)) RETURNS INT AS BEGIN RETURN CASE WHEN @input = '' THEN 1 ELSE LEN(@input) END; END; returns 1 for empty strings using CASE, incorrect. CREATE FUNCTION dbo.StringLength(@input VARCHAR(100)) RETURNS INT AS BEGIN RETURN NULL; END; always returns NULL, which is incorrect.

3. Final Answer:

   CREATE FUNCTION dbo.StringLength(@input VARCHAR(100)) RETURNS INT AS BEGIN RETURN LEN(@input); END; -> Option D

4. Quick Check:

   LEN('') = 0 satisfies condition [OK]

Hint: LEN('') returns 0 for empty strings [OK]

Common Mistakes:

• Returning incorrect value (like 1) for empty strings
• Using overly complex conditional logic unnecessarily
• Returning NULL instead of 0 for empty strings