الاستعلامات الفرعية مقابل CTE وعمليات الربط

In this lesson, we'll explore three fundamental ways to combine and structure data in PostgreSQL: Subqueries, Common Table Expressions (CTEs), and Joins.

Understanding their differences and optimal use cases is key to writing efficient and readable SQL.

You're already familiar with JOINs! They are the primary way to combine rows from two or more tables based on a related column between them.

• Purpose: Link related data across tables.
• Readability: Often straightforward for direct relationships.
• Performance: Highly optimized by PostgreSQL for combining large datasets.

A subquery (or inner query) is a query nested inside another SQL query. It can return a single value (scalar), a single row, a single column, or a table.

• Placement: In SELECT, FROM, WHERE, or HAVING clauses.
• Use Cases: Filtering with IN/EXISTS, calculating aggregate values for comparison, or providing derived tables.

Here's a simple example where a subquery helps find products with prices above the average. Notice how the inner query runs first.

A Common Table Expression (CTE), defined with the WITH clause, creates a temporary, named result set that you can reference within a single SQL statement.

• Purpose: Improve readability, organize complex queries, and enable recursion.
• Scope: Only available for the query immediately following the WITH clause.
• Readability: Breaks down complex logic into logical, readable steps.

Let's rewrite the previous example using a CTE. Notice how it defines "average_price" first, making the main query clearer.

JOINs are your go-to when you need to combine data from different tables that have a direct, logical relationship.

• Direct Relationships: When tables are linked by foreign keys.
• Performance: Highly optimized by the planner for combining large datasets efficiently.
• Result Set: Creates a single, wider result set from matching rows.

They are often the most performant for combining large tables.

Subqueries are useful for specific filtering or calculating values that depend on the main query's data, often acting as a single value or a list.

• Scalar Values: When you need a single value (e.g., WHERE price > (SELECT AVG(price))).
• Filtering: With IN, NOT IN, EXISTS, NOT EXISTS clauses.
• Derived Tables: In the FROM clause for temporary, unnamed result sets.

They can sometimes be less readable for complex logic.

CTEs excel when you need to break down complex queries into logical, readable steps or handle recursive data structures.

• Readability: Improves understanding of multi-step logic.
• Recursion: Essential for querying hierarchical or graph-like data.
• Reusability: A CTE can be referenced multiple times within the same main query.

They are often preferred over complex subqueries for clarity.

Often, a query written with a subquery can be rewritten as a JOIN or a CTE, and vice-versa. PostgreSQL's optimizer is smart!

• Optimizer Role: It often transforms these constructs internally into the most efficient execution plan.
• Readability First: Prioritize clear, maintainable code.
• EXPLAIN ANALYZE: Always use it to truly understand the performance impact of your chosen approach, rather than guessing.

Consider the following scenarios. Which SQL construct is generally the most suitable choice for each?

You've learned to differentiate between JOINs, Subqueries, and CTEs:

• JOINs: Best for direct table relationships and combining large datasets.
• Subqueries: Ideal for scalar values, IN/EXISTS filtering, and derived tables.
• CTEs: Shine for readability, multi-step logic, and recursive queries.

Remember to prioritize readability and use EXPLAIN ANALYZE to confirm performance!