Choosing Fields for a Gear Database: What Actually Gets Used

Every gear database starts the same way. Someone gets excited, builds a table with forty columns, imports a hundred items, and then never touches it again. Six months later the file is a time capsule: half the cells empty, prices from a sale that ended, and no memory of which fields were ever useful.

The fix is not discipline. It is field selection. A database you maintain is one where every field earns its place by being consulted at least occasionally. Here is how to decide which fields deserve to exist.

Start with the decision, not the data

The right question is not "what could I record?" but "what decision does this field help me make?" Fields that never inform a decision become chores.

• Price paid and date paid: tells you whether a current listing is a good deal.

• Blade or body material: drives resale value and care routine.

• Weight: the single most predictive number for whether a tool gets carried.

• Acquired from: tells you which retailer or seller is worth returning to.

• Condition: distinguishes a user from a collectible.

Notice that "SKU" and "manufacturer marketing copy" are missing. They are easy to import, but they never answer a question you actually have.

Use controlled vocabularies or you will regret it

Free-text fields rot. "M390", "m390 steel", "Bohler M390" and "M390 (Bohler)" in four rows means you can never filter reliably.

Pick a closed list for anything with a small number of real options: brand, steel family, lock type, handle material, condition grade. A dropdown takes two seconds longer per entry and saves hours later. For measurements, store the unit in the field name rather than the value so numeric sorting works.

Dates deserve more care than you think

Most people record a purchase date. Fewer record a disposal date. Without both, you cannot answer the most useful question a personal database can answer: how long did this actually last, and was it worth it?

Record acquisition date, first-use date, and disposal or sale date. The gap between them is your real cost of ownership per month, which is far more informative than the sticker price.

Notes are the highest-value field

A short free-text notes field is worth more than ten structured columns, because it captures the things you cannot predict. Why you sold it. Which screw is prone to loosening. What you would change if you bought again. Keep notes to two or three sentences so entering them stays realistic.

Version your data, or lose it

The most common failure mode is not a bad field. It is a bad edit. Change a value in place and the old one is gone forever, along with any chance of noticing that a spec was wrong from the beginning.

Two habits prevent this. First, keep dated exports named by date, so you can compare any two points in time. Second, when a spec is corrected, add a note rather than overwriting silently, so you can see which items were sourced from a bad listing.

Normalise before you compare

If you intend to compare items across brands, you will eventually need to reconcile conflicting numbers: advertised weight versus your own scale, blade length measured tip to handle versus tip to pivot. Decide which measurement is authoritative, record the other separately, and never mix the two in one column.

A database that records authoritative values in consistent units is small, boring, and useful. One that records everything is large, interesting, and abandoned. Start with a dozen fields, add one only when you find yourself writing the same note for the third time, and export on a schedule. If you want to see how a mature, structured gear dataset looks in practice, the item pages at EDC Database show grouped specs, sources and versioned records side by side.

The short version

• Every field must serve a decision you actually make.

• Dropdowns for anything with a small fixed set of values.

• Record both acquisition and disposal dates.

• Keep a short notes field and use it.

• Export on a schedule; never edit destructively.

• One authoritative value per spec, consistent units throughout.

Get those six right and the database survives its second year.