Audit SQL joins for duplicate rows and inflated totals

Check join cardinality and aggregation grain to explain duplicate rows or double-counted measures before changing a reporting query.

PLPromptByte Library@promptbytePublished Sep 8

TextData & Analysis #aggregation #data quality #join cardinality #sql

Version 1 of 1 · published Sep 8, 2026Version 1 · only version

Example output

No public result for version 1 yet

Nobody has shared what a model actually produced from this exact version, and PromptByte never generates examples itself. Run the prompt and add yours to fill this in.

Add your result

Prompt

Version 1 · 2 variables · 2 required

Fill in the values below — the customized prompt updates as you type. marks a required value.

Join query{{join_query}}

The actual reporting SQL. Default: SELECT o.id, SUM(i.amount) AS item_total, SUM(p.amount) AS paid FROM orders o JOIN items i ON i.order_id=o.id JOIN payments p ON p.order_id=o.id GROUP BY o.id;

Table grain{{table_grain}}

Declared keys, relationship cardinality and intended measure grain. Default: orders: one row per order, id primary key. items: many rows per order. payments: possibly several payments per order. Goal: item value and paid amount per order, including unpaid orders.

Customized prompt

live preview

Resolved user prompt10 lines

Audit the correctness of these joins.

Query: SELECT o.id, SUM(i.amount) AS item_total, SUM(p.amount) AS paid FROM orders o JOIN items i ON i.order_id=o.id JOIN payments p ON p.order_id=o.id GROUP BY o.id;
Table grain, keys and business meaning: orders: one row per order, id primary key. items: many rows per order. payments: possibly several payments per order. Goal: item value and paid amount per order, including unpaid orders.

Trace the expected row grain after every join. Identify one-to-many or many-to-many relationships that can multiply measures, missing join predicates, null-key behavior and filters that change outer joins.

Use a small hand-worked example to show any supported multiplication risk; label it illustrative. Explain whether the intended measure belongs to an order, line, payment or other grain. Do not use DISTINCT as a blanket repair.

Propose the smallest correction, such as aggregating each detail relation before joining, and state the semantics it preserves. List checks for key uniqueness, unmatched rows and reconciliation to independent totals. Do not claim the corrected query ran or that inferred keys are real constraints.

Resultsfor version 1

All models

Version 1 · only version

No public examples yet for version 1

Results show what a model actually produced from this exact version. Share yours to help others decide.

code · sql
```
**Assumptions**

- `order_items.order_id` joins to `orders.id`, and `products.category_id` joins to `categories.id`. These are inferred from the naming convention, since no foreign keys were listed.
- "Last 90 days" is measured against `orders.order_date` relative to today, inclusive of today.
- Revenue is `quantity * unit_price` summed over line items; there is no discount or tax column in the schema, so none is applied.
- Cancelled orders are excluded. If `status` uses different values than `'
```
Code preview: **Assumptions** - `order_items.order_id` joins to `orders.id`, and `products.category_id` joins to `categories.id`. These are inferred from the naming convention, since no foreign keys were listed. - "Last 90 days" is measured against `orders.order_date` relative to today, inclusive of today. - Revenue is `quantity * unit_price` summed over line items; there is no discount or tax column in the schema, so none is applied. - Cancelled orders are excluded. If `status` uses different values than `'
SQL query generator from a plain-English request
Converts a natural-language data requirement plus a table schema into a syntactically correct SQL query for a named database, with its assumptions stated up front.
CodeData & Analysis OpenAI · GPT-5.5
PL@promptbyteAug 27
Score 1
0 comments1 results
No public results yet
Design a forecast backtest that respects time and information
Specify temporal evaluation, leakage checks, baselines and business-relevant metrics before judging a forecasting model.
TextData & Analysis
PL@promptbyteSep 8
Score 0
0 comments0 results
No public results yet
Critique an existing chart for misleading interpretation
Review a chart's scales, labels, aggregation and claims, separating visual issues from data questions that need verification.
TextData & Analysis
PL@promptbyteSep 8
Score 0
0 comments0 results
No public results yet
Classify comment sentiment with traceable evidence
Label supplied comments consistently while preserving mixed opinions, unclear cases and the exact words supporting each label.
TextData & Analysis
PL@promptbyteSep 8
Score 0
0 comments0 results
No public results yet
Reshape a wide CSV into tidy records without losing meaning
Produce a deterministic transformation from repeated measure columns to tidy rows with explicit keys, types and missing-value rules.
CodeData & Analysis
PL@promptbyteSep 8
Score 0
0 comments0 results
No public results yet
Define retention cohorts before calculating a heatmap
Specify cohort membership, return behavior and observation maturity so retention percentages remain comparable.
TextData & Analysis
PL@promptbyteSep 8
Score 0
0 comments0 results

Browse Data & Analysis

Example output

Prompt

Customized prompt

Resultsfor version 1

Related prompts

SQL query generator from a plain-English request

Design a forecast backtest that respects time and information

Critique an existing chart for misleading interpretation

Classify comment sentiment with traceable evidence

Reshape a wide CSV into tidy records without losing meaning

Define retention cohorts before calculating a heatmap

Discussion 0