Привет, я посмотрел несколько похожих сообщений на то, что я хочу сделать, но ни один из них не соответствует тому, что мне нужно выполнить. Я пытаюсь придумать свою структуру для категорий с использованием SQL Server 2008 R2.Структурирование категорий в SQL Server 2008 R2
Я хочу сделать категории для let say ... Одежда, электроника, мебель, инструменты ...... и так далее.
Я смотрю таблицу полей 3, чтобы начать с таблицы категорий (идентификатор категории (PK), categoryname, parentID), который из того, что я нахожу, является стандартной практикой и может проходить на несколько слоев без необходимости реструктуризации.
Проблема заключается в том, что это нормально, если вы скажете (электроника-cd player-cd changer), (электроника-освещение-студийное освещение) или (одежда-женские юбки), (одежда-брюки-женщины), возможно, одна уровень глубже?
Что мне делать для брендов? Я планировал иметь таблицу брендов (brandID (PK), Brand) , а затем таблицу Category_Brand (categoryID, BrandID), чтобы связать бренды с категориями, когда я хочу использовать раскрывающийся список каскадов, который заполняется из базы данных.
Что делать для более глубоких атрибутов, когда остальные атрибуты применяются к самому элементу, но зависят от категории? цвет, узор, материал, размер? которые могут применяться к одежде, но не к электронике или инструментам, также мужская одежда имеет различный размер, чем женская одежда. Или мебель, где я хочу хранить размеры и цвет шкафа, или кровати, где я хочу хранить размер кровати (король, королева, близнец) и хранить тип (весна, воздух, пена, вода)
Что мне нужно заключается в подключении атрибутов, специфичных для элемента, к каждому элементу в зависимости от категории, к которой принадлежит элемент. На другом форуме мне предложили просто добавить все разное. атрибуты к таблице элементов и оставить те, которые я не использую null. Я знаю, что это не имеет смысла, мне кажется, что должны быть разные таблицы субатрибутов с полями, которые связаны с категориями, которые они представляют. Я думаю, что размер одежды, например, имел бы таблицу поиска, в которой каждый размер имеет (sizeid) и таблицу ссылок для отношения многих и многих типов, чтобы связать размер с (itemid), хотя там должно быть несколько разные размеры таблиц, так как размеры мужчин и размеры женщин различны или помещаются затем все в одну таблицу с (categoryid) как своего рода родительский внешний ключ, а размеры для другого элемента, такого как длина, ширина и высота, будут храниться в собственном таблицу вместе с (itemid) в качестве внешнего ключа?
Или это хорошая идея сохранить (размер) или (размер) прямо в таблице элементов?
Это было просто для меня, когда я начинал, но чем больше я смотрю на него, тем больше я запутываюсь относительно правильного способа структурирования этого, я хочу, чтобы он работал хорошо для производительности, поскольку это может стать большой объем применения. Но не все ли этого желают?
Результат, который я ищу, заключается в том, что пользователи будут вводить элементы в свои собственные списки, используя выбор категории, а затем могут выбирать прямые атрибуты элемента, соответствующие категории товара. Также пользователи смогут искать в базе данных элементы, используя категории или имена элементов или пользователей, и просматривать результаты элементов с категорией и атрибутами, входящими в этот элемент. –