Question about mongodb way of doing things

Question

Say you're a shop selling products, each with a certain set of properties... for instance let's say you have drills. There are concrete bits, spade bits, etc, but they all have some concept of diameter... so if you have some product {price: 14.95, diameter: 3}, whatever, but decide you want the store to be super generic and allow users to add different properties. There would seem to be a problem if I had a ton of drills and decide "size" would be a better name than "diameter". What would be the best (mongodbish) way to deal with this? Possibly a "drill" category with a list of properties {category_name:"Drills", properties: {"uniqueID1":"diameter", "uniqueID2":"coating"}} or something like that, and then for each drill {price:14.95, properties:{"uniqueID1":3, "uniqueID2":"none"}}. What's the best way to assign the "uniqueID"s, or is there some better way to do this?

Answer 1

Why would you do it like that?

What you call it in the DB doesn't need to reflect what you call it in your app...

So if the item is {price:14.95, pancake:4} it doesn't make any difference, as long as you the developer know that pancake == diameter...

So you could have a list of drillbits

{ name: "Diamond carbide bit", price: 14.95, size: 3 }
{ name: "Cheap ass bit", price: 3.95, size: 3, quality: "poor" }
{ name: "Kryptonite bit", price: 39.95, size: 10, quality: "extreme", comment: "For killing Superman by drill" }

No need to make the properties a "subitem" of the drillbit...