A worked example / Seedloom generator v1.0

Create linked customer and order test data.

Build a tiny, repeatable fixture for a store prototype: six fictional customers, eighteen orders, and a customer ID that actually joins. Follow the recipe, inspect the rows, then export CSV or SQLite SQL.

Try this sample in Seedloom →

Loads the recipe into tab memory. Click Generate dataset in the app. No account or donation required.

6 + 18customers and orders

0orphaned order references

1 seeda repeatable starting point

1. Start with the relationship.

An order belongs to a customer, so create customers first and orders second. Seedloom references the sequential primary ID of an earlier table. This gives you a usable join instead of two unrelated lists.

Use the exact seed customers-orders-guide-v1. Keep the table order, field order, row counts, bounds, and choices below unchanged to reproduce the downloadable results with generator v1.0.

customers · 6 rows

id: Sequential ID, the primary key
name: Example name
email: Example email, Unique enabled

All fields: Null % = 0. Name uniqueness is off. IDs are always unique.

orders · 18 rows

id: Sequential ID
customer_id: Parent reference → customers
total: Decimal, 10 through 99
status: Weighted choices: paid = 3, pending = 1

All fields: Null % = 0. Leave uniqueness off except for the primary ID.

Do not make customer_id unique: one customer can have several orders. The 3:1 status weights describe probabilities, not a promise that exactly 75% of a small sample will be paid. This fixture has 15 paid and 3 pending orders.

2. Generate, then inspect both tables.

Use the sample button above, or download the recipe below and choose Import in Seedloom. If importing into existing work, back up your current schema first.
Check the seed and click Generate dataset. The status should say 24 synthetic rows ready.
Select customers, then orders in the table tabs. Each preview shows all rows here because both tables are below the 30-row preview cap.
Use CSV once for each selected table. Use JSON or SQLite SQL to export both tables together.

The first three orders you should see

id	customer_id	total	status
1	5	14.43	paid
2	1	14.18	paid
3	6	50.04	pending

Customer 5 is Avery Meadow, customer 1 is Gray Meadow, and customer 6 is Kai Grove in this fictional fixture. Names come from small example lists; emails use the reserved example.test domain.

If your rows differ, compare the full recipe, not just the seed. Changing even a row count or field order changes how random values are consumed. Keep the recipe alongside your exported fixture.

3. Verify the SQLite export before using it.

The supplied SQL creates new customers and orders tables and inserts the fixture. Review it, then run it in a fresh, disposable SQLite database. Do not load test fixtures into production.

Enable foreign keys before importing the SQL. In the SQLite command-line shell, with the sample SQL file in the current directory:

sqlite3 :memory:
PRAGMA foreign_keys = ON;
.read customers-orders.sql
SELECT COUNT(*) FROM customers; -- 6
SELECT COUNT(*) FROM orders;    -- 18
PRAGMA foreign_key_check;       -- no rows

The .read line is a SQLite shell command, not portable SQL. In a database GUI, enable foreign keys and open/run the SQL file instead.

Check for orders without customers

SELECT COUNT(*) AS orphaned_orders
FROM orders AS o
LEFT JOIN customers AS c ON c.id = o.customer_id
WHERE c.id IS NULL;
-- Expected: 0

These exact sample files were executed in SQLite with foreign keys enabled: 6 customers, 18 orders, zero orphaned orders, and no foreign-key violations.

A small join proves the data is useful

SELECT o.id, c.name, o.total, o.status
FROM orders AS o
JOIN customers AS c ON c.id = o.customer_id
ORDER BY o.id
LIMIT 3;

The join returns Avery Meadow / 14.43 / paid, Gray Meadow / 14.18 / paid, and Kai Grove / 50.04 / pending, in order. This is enough to test an order-list screen or an API fixture loader.

Download the recipe and the result.

Small fictional test inputs and outputs, ready to inspect. The recipe is schema-only; the other files contain the generated rows. CSV uses spreadsheet-safe export settings.

Recipe JSON Customers CSV Orders CSV SQLite SQL Dataset JSON

Adapt the fixture carefully

Increase the row counts when you need pagination tests. Add nulls when you need empty-state handling. Keep the original recipe as a baseline, and expect changed outputs after any edit. A reference can repeat, and random assignment does not guarantee every customer receives an order in every recipe.

Privacy and exact limits.

Generation, schema import, and exports run in your browser. Seedloom has no dataset-upload API, analytics, external fonts, or runtime CDNs. The host serves page assets and may keep ordinary access logs. Downloads stay wherever your browser saves them.

The app uses tab memory by default. “Remember schema on this device” is optional and stores only the schema in this browser profile. The tutorial link does not overwrite an already saved schema. Custom field names and choices can contain personal data if you type it; Seedloom is not an anonymizer. Use fictional content and no secrets.

50,000 total rows, 500,000 cells, 5 tables, and 30 fields per table.
Schema imports: at most 100,000 bytes. Each output: at most 50 MiB. Device memory may impose a tighter limit.
References point only to earlier tables. No circular relations, hosted API, arbitrary expressions, or real-data enrichment.
The seeded generator is not cryptographic. Names may coincidentally match real people. Reproduction depends on generator version and the complete recipe.
CSV nulls become empty cells. Spreadsheet-safe CSV prefixes formula-like strings, headers, and negative numbers with an apostrophe. JSON preserves types and nulls; SQL targets SQLite.

Use the fixture to test structure and behavior. It is not a model of real customer behavior or a privacy guarantee for data you add yourself.