Kedis ku xidhan hagaha · Dhexdhexaad Heerka
Sida Loo Fahmo SQL Ku biirista AI Kediska
Ku celceli natiijooyinka ka-qaybgalka gudaha iyo dibadda, isku-dhufashada badan-ilaa-badan oo isku-dhufashada iyo meelaynta shaandhaynta adoo isticmaalaya macmiil yar oo dalbo tusaalayaal.
Su'aal 1 ee 8
Ada has two orders and Ben has none. How many rows result from the guide's customer-to-order left join before further filtering?
Horudhac su'aal kasta8 su'aalo
Jawaabaha iyo sharraxaadaha waxay soo baxayaan markaad qaadanayso kediska.
- 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
- Three order lines and two promotion records share a product key. How many matching combinations does an equality join on that key produce?
- Lix
- Shan
- Saddex
- Laba
- 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
- 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
- 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
- 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
- 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
- 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