DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • How to Pivot and Join Time Series Data in Flux
  • MongoDB to Couchbase: An Introduction to Developers and Experts
  • The Aggregate Reference Problem
  • The Serverless Ceiling: Designing Write-Heavy Backends With Aurora Limitless

Trending

  • Optimizing High-Volume REST APIs Using Redis Caching and Spring Boot (With Load Testing Code)
  • How to Parse Large XML Files in PHP Without Running Out of Memory
  • Build a GitHub Slack Bot With AWS Bedrock and MCP, Part 2
  • Testing AI-Infused Apps: A Dual-Layer Framework for AI Quality Assurance
  1. DZone
  2. Data Engineering
  3. Databases
  4. 5 Absolutely Must-Know Differences Between JOINs and Sub-Queries in DB2

5 Absolutely Must-Know Differences Between JOINs and Sub-Queries in DB2

JOINs and sub-queries are similar but different. See what you can do with them and when it's best to use one one over the other.

By 
Srini Pesala user avatar
Srini Pesala
·
Aug. 27, 16 · Tutorial
Likes (1)
Comment
Save
Tweet
Share
30.1K Views

Join the DZone community and get the full member experience.

Join For Free

JOINs and sub-queries resolve your data retrieval problems when data is located in multiple tables. But whether you use a JOIN or a sub-query is a tricky subject discussed in many forums. The step-by-step points below will help you get a solid footing.

DB2 Joins

  1. JOINs are powerful relational operators that combine data from multiple tables into a single result table.

  2. The source tables may have little (or even nothing) in common with each other. SQL supports a number of types of JOINs.

  3. Any multitable query is a type of JOIN. The source tables are joined in the sense that the result table includes information taken from all the source tables.

  4. The simplest JOIN is a two-table SELECT that has no WHERE clause qualifiers. Every row of the first table is joined to every row of the second table. The result table is referred to as the Cartesian product of the two source tables — the direct product of the two sets. (The less fancy name for the same thing is a cross JOIN.) The number of rows in the result table is equal to the number of rows in the first source table multiplied by the number of rows in the second source table.

DB2 Sub-Queries

  1. A sub-query is an SQL statement that is embedded within another SQL statement. It’s possible for a sub-query to be embedded within another sub-query, which is in turn embedded within an outermost SQL statement. Theoretically, there is no limit to the number of levels of sub-queries that a SQL statement may include, although any given implementation has a practical limit.

  2. A key feature of a sub-query is that the table or tables that it references need not be the same as the table or tables referenced by its enclosing query.

  3. Different kinds of nested queries produce different results. Some sub-queries produce a list of values that is then used as input by the enclosing statement. Other sub-queries produce a single value that the enclosing statement then evaluates with a comparison operator. A third kind of sub-query is called a correlated sub-query, which is nested within another query and uses information from it.

Tips to Use in Your SQL Queries:

  • When you are dealing with more tables, JOIN is good.
  • When you are dealing with fewer tables, sub-queries are good.
  • When you need data for the NOT EXISTS and EXISTS conditions, you can use sub-queries.
  • You can use both JOINs and sub-queries together in same SQL query.
Relational database Database Joins (concurrency library)

Opinions expressed by DZone contributors are their own.

Related

  • How to Pivot and Join Time Series Data in Flux
  • MongoDB to Couchbase: An Introduction to Developers and Experts
  • The Aggregate Reference Problem
  • The Serverless Ceiling: Designing Write-Heavy Backends With Aurora Limitless

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook