A fictional wholesale desk-accessory supplier
The order is in. What hasn’t left?
Learn to read, filter and group order data, then see why a direct shipment join double-counts value. Start with one table; build toward the unshipped-value question.
Starting the local database. The first load includes a bundled WebAssembly engine.
02 / ASK THE DATABASE
Start with a question.
Try the large-data investigation and supplied answer
SQL edits and the one-step restore stay only in this tab. Use Save SQL before leaving; reload restores the first starter. Selecting a starter replaces the editor, with Restore previous query available.
Edits wait for Run query so you can finish a statement. One read-only query · 8-second limit · 500 retained result rows. Ctrl / ⌘ + Enter also runs it.
03 / INSPECT THE ANSWER
Query results
The result table will appear when the database is ready.
CSV includes all retained rows, up to 500; each table page shows up to 50. Save the matching note with the CSV for the executed SQL, dataset and units. Save SQL above saves the current editor, which may differ.
SQL that produced these results
Column names and storage types
Why shipment events are not order lines
Line A contains 10 notebooks at $20 each. Two events ship 3 and 2 units. Joining A directly to both events repeats its $200 order value twice. The naive tiny-case query therefore returns $750 instead of $550.
First sum shipped units by line_id. Then left join that one-row-per-line result to line_items. Missing shipments become zero; A keeps its original 10 units and gets 5 shipped. Unshipped units × original unit price gives unshipped order value.
The $275 outstanding is merchandise that has not shipped. It is not accounts receivable, profit, a due-date measure or a forecast of cancellations. All examples are invented and exclude tax, freight and cost data.
Limits, precision and local execution
The database and its worker are bundled with the app; no SQL or data is sent to a server. The first load downloads the engine from this site. All tables are synthetic. Changing datasets or resetting destroys the worker and rebuilds the selected example; query text is preserved. Reload restores the large example and the first starter query.
DuckDB’s native lexer handles a final semicolon; its prepared-statement parser accepts one bounded SELECT expression. Each run executes in a native READ ONLY transaction. Extension installation/loading and external access are disabled, and configuration is locked. This is a bounded local classroom workspace, not a general database administration console.
Order prices are integer USD cents. The table preserves BIGINT and DECIMAL values as exact strings. The known integer columns unit_price_cents, gross_cents, shipped_cents and outstanding_cents display exact USD. Whole dollars omit .00. Other aliases and noninteger types remain raw; a name alone cannot establish a new unit. The optional chart converts safe known cents to USD. CSV always retains raw values and original names; the exact table remains the display reference.
We request at most 501 result rows to detect the 500-row result cap, and show 50 per page. A cap limits returned rows, not all intermediate computation. Use ORDER BY for a stable order. An 8-second limit or Cancel terminates the actual worker; reset to continue. A 128MB database memory budget, 16KiB SQL limit and 30-column display limit keep mistakes recoverable. No guarantee is made for arbitrary heavy queries or every browser.
Charts require exactly two columns: unique nonempty text categories and finite numeric values within safe display bounds, at most 20 uncapped rows. Other results remain fully usable as a table. Downloaded CSV includes at most the 500 retained result rows; spreadsheet-formula text is escaped.