0Pricing
PostgreSQL Performance & Query Optimization · Leçon

Sous-requêtes, CTE ou jointures

Comparez les sous-requêtes, les expressions de table communes (CTE) et les jointures afin de construire vos requêtes de manière optimale.

Sous-requêtes, CTE ou jointures est une leçon PostgreSQL Performance & Query Optimization gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage PostgreSQL Performance & Query Optimization, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours PostgreSQL Performance & Query Optimization comprend 4 leçons au total.

Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.

Welcome to Query Construction

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.

Joins: The Foundation

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.

What are Subqueries?

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.

Subquery in Action

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

CREATE TABLE products (
  product_id SERIAL PRIMARY KEY,
  product_name VARCHAR(50),
  price DECIMAL(10, 2)
);

INSERT INTO products (product_name, price) VALUES
('Laptop', 1200.00),
('Mouse', 25.00),
('Keyboard', 75.00),
('Monitor', 300.00),
('Webcam', 50.00);

SELECT product_name, price
FROM products
WHERE price > (SELECT AVG(price) FROM products);

DROP TABLE products;

What are CTEs?

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.

CTE in Action

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

CREATE TABLE products (
  product_id SERIAL PRIMARY KEY,
  product_name VARCHAR(50),
  price DECIMAL(10, 2)
);

INSERT INTO products (product_name, price) VALUES
('Laptop', 1200.00),
('Mouse', 25.00),
('Keyboard', 75.00),
('Monitor', 300.00),
('Webcam', 50.00);

WITH AverageProductPrice AS (
  SELECT AVG(price) AS avg_price
  FROM products
)
SELECT p.product_name, p.price
FROM products p, AverageProductPrice app
WHERE p.price > app.avg_price;

DROP TABLE products;

Choosing Joins

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.

Choosing Subqueries

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.

Choosing CTEs

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.

Performance: It's Complicated!

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.

Compare & Contrast

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

Recap: Constructing Optimal Queries

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!

Questions Fréquemment Posées

La leçon « Sous-requêtes, CTE ou jointures » est-elle gratuite ?

Oui — le texte complet de « Sous-requêtes, CTE ou jointures » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours PostgreSQL Performance & Query Optimization, passe à CoddyKit PRO. Le cours PostgreSQL Performance & Query Optimization comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Sous-requêtes, CTE ou jointures » ?

Comparez les sous-requêtes, les expressions de table communes (CTE) et les jointures afin de construire vos requêtes de manière optimale. Tu pratiques PostgreSQL Performance & Query Optimization avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer PostgreSQL Performance & Query Optimization ?

Aucune expérience préalable n'est requise. PostgreSQL Performance & Query Optimization sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.

Combien de temps prend la leçon « Sous-requêtes, CTE ou jointures » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon PostgreSQL Performance & Query Optimization ?

Oui. Chaque leçon PostgreSQL Performance & Query Optimization inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. Comprendre les algorithmes de jointure
  2. Réécrire des jointures complexes
  3. Sous-requêtes, CTE ou jointures
  4. Optimiser les jointures LATERAL et les recherches corrélées
← Retour à PostgreSQL Performance & Query Optimization