Есть два способа придумать что-то подобное.Однако первое, что нужно признать, это то, что ваши данные по своей структуре иерархичны и не обязательно очень регулярны.Это означает, что использование традиционной реляционной базы данных не будет особенно подходящим для данных этого типа.Тем не менее, это может быть сделано.
Первый способ, которым я бы, вероятно, воспользовался, - это выбрать нереляционную базу данных, такую как MongoDB, которая предназначена для хранения коллекций «документов».Документ, в сущности, немного похож на объект и может содержать другие встроенные документы в. Это было бы особенно полезно для данных вашего типа.Вы можете создать модель данных следующим образом:
Item {
main_options: [{
name: "Shape",
sub_options: [{
name: "1/2 Circle",
// Other fields here
}]
},
{
// Other main option
}]
}
Прелесть этого типа модели данных на основе документов заключается в том, что существует нет фиксированной схемы, которой вы должны придерживаться.Если элементу требуется несколько вложенных наборов параметров, вы просто идете вперед и определяете документ этого элемента таким образом.Несмотря на то, что каждый «элемент» документа потенциально сильно отличается, все они хранятся в одной «коллекции», и вы можете выполнять запросы для поиска различных элементов.Таким образом, вы можете попросить базу данных найти все элементы с подопцией «1/2 Circle», например, «Shape».
Если вы привыкли работать с реляционными базами данных, переходя к чему-то вроде MongoDBэто что-то вроде изменения сознания, но я думаю, что в этом случае это вполне соответствовало бы природе ваших данных.
С другой стороны, если вам абсолютно необходимо использовать реляционную базу данных, вынужно моделировать вещи как иерархию, которая может быть немного сложнее.В основном вам нужны таблицы, немного похожие на те, что вы уже описали, хотя я переформулировал их с изменениями, которые я сделал бы здесь:
item (id (pk), name: text, ...)
option (id (pk), owner: option_id (fk), name: text, ...)
item_options (item_id, option_id)
Итак, здесь мы определяем нашу таблицу элементов и другую таблицу, которая сопоставляет элемент сэто набор основных опций, которые определены в таблице «option».
В таблице опций есть дополнительное поле «owner», которое для основных опций вы бы установили в «null», но для вложенныхпараметры, вы должны установить в этом поле идентификатор опции основной опции или, возможно, подопцию, которая «владеет» ею.Используя такую структуру, вы можете вкладывать свои параметры на любую глубину.Вот некоторые примеры данных:
item (1, "Sofa", ...)
option (1, null, "Shape", ...)
option (2, null, "Length", ...)
option (3, 1, "1/2 Circle", ...)
option (4, 1, "3/4 Circle", ...)
option (5, 2, "Short", ...)
option (6, 2, "Long", ...)
option (7, 5, "Specific Short Measurement", ...)
option (8, 5, "Other Short Measurement", ...)
item_options (1, 1)
item_options (1, 2)
Недостатком использования реляционной базы данных для этого типа данных является то, что запросы для поиска вещей не очень просты.Например, чтобы найти все диваны с параметром «1/2 круга», вам может понадобиться что-то вроде:
select * from item i inner join item_options io on i.id = io.item_id inner join option o on io.option_id = o.id left join option o2 on o.id = o2.owner where o.name = 'Shape' and o2.name = '1/2 Circle';
Как видите, чем глубже структура вашего элемента, тем больше у вас соединенийсделать запрос чего-то глубоко в иерархии.И этот запрос только для чего-то с только основными и подопциями.
В любом случае, я надеюсь, что это даст вам несколько вариантов того, как моделировать вещи.