In the first post of this series we set the stage for the Backyard Quarry project.
Once you decide every rock in the yard should have a record, the next question appears immediately:
What exactly should we record?
It’s a deceptively simple question. And like most simple questions in engineering, it opens the door to a surprisingly large number of decisions.
The First Attempt
The most straightforward approach is to keep things minimal.
Each rock gets an identifier and a few attributes.
Something like:
rock_id
size
price
At first glance, this seems reasonable.
We can identify the rock. We can describe it in some vague way. We can assign a price.
But this model breaks down almost immediately.
“Size” is ambiguous. Is that weight? Volume? Longest dimension? All of the above?
Two rocks of the same “size” might behave very differently when you try to move them.
And more importantly, this model doesn’t capture anything about the rock beyond its most basic characteristics.
It’s enough to sell a rock.
It’s not enough to understand one.
Expanding the Model
To make the system more useful, we need to be more explicit.
A slightly richer model might look like this:
rock_id
weight_lb
length_cm
width_cm
height_cm
color
rock_type
location_found
status
Now we’re getting somewhere.
We can distinguish between rocks that look similar but behave differently.
We can track where each rock came from.
We can start to answer questions like:
- How many rocks do we have in a given area?
- What size distribution does the dataset have?
- Which rocks are suitable for different uses?
This is the point where the rock pile starts to feel less like a random collection and more like a dataset.
The Object Data Model
At a higher level, what we’re really doing is separating a physical object into a few distinct components.
Each rock has:
- metadata describing its properties
- images representing its appearance
- optionally, a 3D model capturing its shape
This separation turns out to be important.
Metadata is small, structured, and easy to query.
Images and 3D models are large, unstructured assets that need to be stored and referenced.
Keeping those concerns separate is a pattern that shows up in many real-world systems.
The Identity Problem
Once the schema starts to take shape, another question appears.
How do we uniquely identify a rock?
There are a few options:
- sequential IDs (
rock_001,rock_002) - UUIDs
- physical tags attached to rocks
- some form of image-based identification
For a small backyard dataset, almost anything works.
But the choice matters more as the system grows.
Sequential IDs are easy to read but require coordination.
UUIDs are globally unique but harder to work with manually.
Physical tags introduce a connection between the digital record and the real-world object.
Even in a simple system, identity becomes a design decision.
Classification: The Quarry Taxonomy
At some point, it becomes useful to introduce categories.
Originally this was just a convenience.
But like many things in this project, it quickly became something more formal.
A simple classification system might look like this:
Class 0 — Pebble
Class 1 — Hand Sample
Class 2 — Landscaping Rock
Class 3 — Wheelbarrow Class
Class 4 — Engine Block Class
Class 5 — Heavy Machinery Class
Each class roughly corresponds to how the rock is handled.
This turns out to be surprisingly useful.
Instead of asking for exact dimensions, we can filter by class:
- “Show me all Pebble Class rocks”
- “Exclude anything above Wheelbarrow Class”
In other words, we’ve introduced a derived attribute — something computed from the underlying data rather than stored arbitrarily.
This is exactly how classification systems evolve in real datasets.
Thinking About Lifecycle
Rocks don’t change much physically, but their role in the system does.
A rock might move through states like:
collected
cataloged
listed_for_sale
sold
Tracking this lifecycle introduces another dimension to the data.
Now we’re not just modeling objects.
We’re modeling *objects over *.
Even in a simple system, state and transitions begin to matter.
The Tradeoffs
At this point, the schema is already doing useful work.
But it’s also clear that there’s no perfect design.
Every decision involves tradeoffs:
- more fields vs simplicity
- normalized structure vs ease of use
- flexibility vs consistency
The goal isn’t to design the perfect schema on the first try.
The goal is to design something that can evolve.
Because as soon as we start capturing real data, we’ll learn what we got wrong.
What Comes Next
With a basic schema in place, the next challenge becomes obvious.
We know what we want to store.
Now we need to figure out how to capture it.
In the next post, we’ll look at how to turn a physical rock into images, measurements, and potentially a 3D model — and how that process introduces its own set of constraints.
Because it turns out that collecting data from the physical world is rarely as clean as designing a schema on paper.
