Why table design matters in SQL - Performance Analysis

Time Complexity: Why table design matters

O(n)

Understanding Time Complexity

Good table design affects how fast database queries run. We want to see how the structure of tables changes the work needed to get data.

How does the way we build tables impact the speed of data retrieval?

Scenario Under Consideration

Analyze the time complexity of this simple query on two different table designs.

-- Query to find all orders for a customer
SELECT * FROM Orders WHERE CustomerID = 123;

-- Table design 1: Orders with CustomerID indexed
-- Table design 2: Orders without index on CustomerID
    

This query fetches all orders for one customer. The difference is whether CustomerID is indexed or not.

Identify Repeating Operations

Look at what the database does repeatedly to answer the query.

• Primary operation: Searching rows in the Orders table for matching CustomerID.
• How many times: Once per row in the table if no index; fewer times if an index is used.

How Execution Grows With Input

Think about how the work changes as the number of orders grows.

Input Size (n)	Approx. Operations Without Index
10	10 row checks
100	100 row checks
1000	1000 row checks

Pattern observation: Without an index, the database checks every row, so work grows directly with table size.

Final Time Complexity

Time Complexity: O(n)

This means the time to find orders grows in direct proportion to how many orders there are.

Common Mistake

[X] Wrong: "Adding more columns to a table always slows down queries significantly."

[OK] Correct: The main factor is how the table is organized and indexed, not just the number of columns.

Interview Connect

Understanding how table design affects query speed shows you know how to build databases that work well as they grow. This skill helps you write faster queries and design better systems.

Self-Check

"What if we added an index on CustomerID? How would the time complexity change when searching for orders?"

Practice

1. Why is it important to design tables properly in a database?

easy

A. To keep data organized and easy to find

B. To make the database look colorful

C. To increase the size of the database unnecessarily

D. To confuse users with complex structures

Solution

1. Step 1: Understand the purpose of table design

   Good table design organizes data logically so it is easy to access and manage.

2. Step 2: Identify the benefits of proper design

   Proper design improves speed and reduces errors in data handling.

3. Final Answer:

   To keep data organized and easy to find -> Option A

4. Quick Check:

   Good design = organized data [OK]

Hint: Good design means organized, fast, and error-free data [OK]

Common Mistakes:

• Thinking design is about appearance
• Ignoring data organization
• Assuming bigger tables are better

2. Which of the following is the correct way to define a primary key in a SQL table?

easy

A. CREATE TABLE users (id INT, name VARCHAR(50) UNIQUE PRIMARY);

B. CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(50));

C. CREATE TABLE users (id INT KEY PRIMARY, name VARCHAR(50));

D. CREATE TABLE users (id INT, name VARCHAR(50) PRIMARY);

Solution

1. Step 1: Review SQL syntax for primary key

   The correct syntax places PRIMARY KEY after the column type.

2. Step 2: Check each option's syntax

   CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(50)); correctly uses 'id INT PRIMARY KEY'. Others misuse keywords or order.

3. Final Answer:

   CREATE TABLE users (id INT PRIMARY KEY, name VARCHAR(50)); -> Option B

4. Quick Check:

   PRIMARY KEY follows column type [OK]

Hint: PRIMARY KEY goes right after the column type [OK]

Common Mistakes:

• Placing PRIMARY before KEY
• Using UNIQUE and PRIMARY together incorrectly
• Misordering keywords

3. Given the table employees(id INT PRIMARY KEY, name VARCHAR(50), department_id INT) and departments(id INT PRIMARY KEY, name VARCHAR(50)), what will this query return?

SELECT e.name, d.name FROM employees e JOIN departments d ON e.department_id = d.id;

medium

A. A list of all employees without department names

B. A syntax error due to missing WHERE clause

C. A list of employee names with their department names

D. A list of department names only

Solution

1. Step 1: Understand the JOIN operation

   The JOIN matches employees with departments where department_id equals department's id.

2. Step 2: Analyze the SELECT columns

   The query selects employee names and their matching department names.

3. Final Answer:

   A list of employee names with their department names -> Option C

4. Quick Check:

   JOIN on keys returns combined rows [OK]

Hint: JOIN matches rows by keys to combine related data [OK]

Common Mistakes:

• Thinking JOIN needs WHERE clause
• Expecting only one table's data
• Confusing JOIN with UNION

4. You have a table orders(order_id INT, customer_id INT, order_date DATE) but forgot to set a primary key. What problem might this cause?

medium

A. Duplicate orders might be stored without warning

B. The database will reject all inserts

C. Queries will run faster automatically

D. You cannot store dates without a primary key

Solution

1. Step 1: Understand the role of primary keys

   Primary keys ensure each row is unique and prevent duplicates.

2. Step 2: Identify consequences of missing primary key

   Without a primary key, duplicate rows can be inserted without errors.

3. Final Answer:

   Duplicate orders might be stored without warning -> Option A

4. Quick Check:

   No primary key = possible duplicates [OK]

Hint: Primary key prevents duplicate rows [OK]

Common Mistakes:

• Thinking inserts are blocked without primary key
• Assuming primary key affects date storage
• Believing queries always run faster without keys

5. You want to design a table to store product reviews with columns: review_id, product_id, user_id, rating, and comment. Which design choice improves efficiency and avoids mistakes?

hard

A. Store all data in one text column to simplify

B. Make all columns PRIMARY KEY to ensure uniqueness

C. Use only product_id as PRIMARY KEY and ignore others

D. Set review_id as PRIMARY KEY and product_id, user_id as FOREIGN KEYS

Solution

1. Step 1: Identify keys for uniqueness and relationships

   review_id uniquely identifies each review, so it should be PRIMARY KEY.

2. Step 2: Use FOREIGN KEYS for related data

   product_id and user_id link to other tables, so they should be FOREIGN KEYS.

3. Step 3: Evaluate other options

   Making all columns PRIMARY KEY is invalid; using one key ignores uniqueness; storing all data in one column loses structure.

4. Final Answer:

   Set review_id as PRIMARY KEY and product_id, user_id as FOREIGN KEYS -> Option D

5. Quick Check:

   Primary and foreign keys keep data correct and linked [OK]

Hint: Use primary key for unique ID, foreign keys for links [OK]

Common Mistakes:

• Making multiple columns primary keys incorrectly
• Ignoring foreign key relationships
• Storing all data in one column