Orders whose keys resolve.

Take a file, or take three

Take this with customers-1000.csv and products-100.csv and you have a three-table join that reconciles exactly. That combination is the reason this dataset exists.

Bigger sizes, built here

At larger sizes the keys stay inside the same space: customer_id 1001 to 2000 and SKU-1001 to SKU-1060. A million orders still join cleanly against the 1,000-row customers file, which is what makes this a fair test of a join at scale.

Ten columns, and what each one holds

What it models

An order header table from a small e-commerce system: who ordered, what they ordered, when, how it went, and what it cost. One row is one order for one SKU, which is a simplification real systems avoid, and it is the right simplification here because it keeps the join two-dimensional and the arithmetic visible on the row.

Statuses are weighted the way a real order table is weighted: delivered dominates, shipped and processing are the live tail, and returned and cancelled are the small unhappy fraction that every revenue query has to decide what to do about. That decision, whether to filter them out before summing, is exactly the question a sample dataset should be forcing you to ask.

Why the join is the point

Most sample order files have a customer_id column full of random integers that point at nothing. You can write the JOIN, but you cannot check the answer, because there is no other side. Here there is: customer_id is always between 1001 and 2000, which is precisely the range in the 1,000-row customers file, and sku is always between SKU-1001 and SKU-1060, which is inside the 100-row products file.

So an inner join loses no rows, a left join produces no nulls, and a count before and after the join is the same number. When you are learning joins, or testing a tool's join, that property is what tells you whether the result is right. If your join drops rows against these files, the join is wrong, not the data.

There is a second, sharper check available. unit_price on an order is the catalog price for that SKU, so joining orders to products and comparing orders.unit_price against products.price must return zero mismatches across all 1,000 rows. A test in the repository asserts exactly that.

The money columns

subtotal is quantity multiplied by unit_price. shipping is a flat band that drops to 0.00 once subtotal passes 75.00, which puts a real conditional into the data instead of a smooth number. total is subtotal plus shipping. All three are computed and rounded once, so no floating point residue leaks into the file and no row is off by a cent.

That free shipping threshold is more useful than it looks. It gives you a genuine discontinuity to find: bucket orders by subtotal, chart mean shipping, and the cliff at 75.00 shows up immediately. It is a good first exercise in "the data has a rule in it, find the rule".

The three files that fit together

customer_id is 1001-2000 and sku is SKU-1001 to SKU-1060; unit_price is the catalogue price for that SKU, so a three-way join reconciles to the cent.

Download all three and the exercise writes itself: join orders to customers on customer_id, join the result to products on sku, then group by plan and category. Because the price on the order is the catalog price, the totals reconcile exactly, so you can tell the difference between a wrong answer and an approximate one.

Open it somewhere useful

The merger is the one to try here, because it is the only tool on the site where the join key matters.

Questions people ask about this file