The Backyard Quarry, Part 2: Designing a Schema for Physical Objects
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 s...

Source: DEV Community
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