thebench.bio #1 Ecosystem for the Bio-Tech Industry
All SQL questions

Question 2 of 6 Intermediate Scenario

How would you investigate unexpectedly duplicated rows after a join?

Short answer

First establish the intended row grain and inspect duplicate join keys on both inputs. A many-to-many match can expand rows even when both input tables are internally valid.

Why

Suppose 100 subjects each have multiple visits, while one lab table has multiple analytes per visit. Joining solely on subject_id creates a product of visits and analytes, not a valid visit-level match. Check counts, distinct composite keys and the multiplicity of each proposed join relationship.

Test candidate keys such as (subject_id, visit_id, analyte_id) according to documented data semantics. Look at unmatched records as well as duplicated rows, since both can hide incorrect relationships. Summarizing to subject level before the join may work only if the chosen statistic matches the scientific question and preserves missingness.

Adding DISTINCT to make counts look plausible can silently remove genuine observations. Document pre or post row counts, uniqueness tests, known exceptions and an example trace from original records to the analytic output.

Common mistakes

  • Using DISTINCT as an automatic repair for a mistaken many-to-many join