Jak zrozumieć połączenia SQL za pomocą quizu AI

Odpowiedzi i wyjaśnienia pojawiają się w miarę rozwiązywania quizu.

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?
   • Sześć
   • Pięć
   • Trzy
   • Dwa
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