Вопрос о mongodb способе ведения дел

Question

Скажем, вы магазин, продающий продукты, каждый с определенным набором свойств ... например, скажем, у вас есть упражнения.Существуют бетонные, лопаточные и т. Д., Но все они имеют некоторую концепцию диаметра ... так что если у вас есть какой-то продукт {цена: 14,95, диаметр: 3}, что угодно, но решите, что вы хотите, чтобы магазин был супер универсальным ипозволяют пользователям добавлять различные свойства.Казалось бы, возникла бы проблема, если бы у меня была тонна упражнений, и я решил, что «размер» будет лучшим названием, чем «диаметр».Каков наилучший (mongodbish) способ справиться с этим?Возможно, категория «сверление» со списком свойств {category_name: «Drills», свойства: {«uniqueID1»: «диаметр», «uniqueID2»: «покрытие»}} или что-то в этом роде, а затем для каждой детали {цена: 14.95, свойства: {"uniqueID1": 3, "uniqueID2": "нет"}}.Каков наилучший способ присвоить "uniqueID" или есть лучший способ сделать это?

Answer 1

Зачем вам это так?

То, что вы называете в БД, не должно отражать то, что вы называете в своем приложении ...

Так что, если элемент{цена: 14,95, блин: 4} это не имеет никакого значения, пока вы разработчик знает, что блин == диаметр ...

Таким образом, вы можете иметьсписок сверл

{ 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" }

Нет необходимости делать свойства "подпунктом" сверла ...