How to Understand SQL Joins with AI Quiz

Answers and explanations appear as you take the quiz.

1. Ada has two orders and Ben has none. How many rows result from the guide's customer-to-order left join before further filtering?
   • Two, because only orders are counted
   • One, because customer names are unique
   • Three, including Ben's unmatched row
   • Four, because every customer gets two rows
2. Three order lines and two promotion records share a product key. How many matching combinations does an equality join on that key produce?
   • Six
   • Five
   • Three
   • Two
3. A report should contain one row per customer, but a join currently returns one row per order. What should be clarified before accepting the query?
   • Whether sorting the result by customer removes the extra order rows
   • Whether selecting fewer order columns alone changes the output grain
   • Whether renaming the customer key makes it unique in the joined result
   • The intended output grain and how order data should be aggregated
4. A left join should keep customers without shipped orders. Where might a condition restricting matches to shipped orders belong?
   • In a WHERE condition that rejects all null right-side values
   • In the ON condition that controls which orders match
   • Only in the final ORDER BY clause
   • In a DISTINCT operation after all orders have been joined
5. Why is adding DISTINCT not a reliable general fix for inflated totals after a many-to-many join?
   • DISTINCT establishes one row per customer regardless of which columns are selected
   • DISTINCT makes each join-key value unique before matching occurs
   • It may hide duplicate-looking results without correcting the matching or aggregation logic
   • DISTINCT guarantees that an aggregate computed after the join used each source amount once
6. Which join preserves unmatched rows from both input tables?
   • A full outer join
   • An inner join
   • A left join in every table order
   • A self join regardless of its join type
7. After a left join, why can COUNT(*) differ from COUNT of a non-null right-side identifier?
   • COUNT(*) counts only distinct customers
   • COUNT of the identifier includes every null-extended row
   • COUNT(*) automatically removes duplicate join keys
   • COUNT(*) includes unmatched output rows while the identifier count excludes their nulls
8. An AI explanation assumes ordinary equality will match two null join-key values. How should that claim be treated?
   • Accept it because both sides contain the same missing-value marker
   • Correct it using the database's null semantics
   • Accept it because an outer join changes equality comparisons involving null
   • Assume two null keys match whenever both source columns have the same data type