2014-09-23 7 views
0

Привет, я посмотрел несколько похожих сообщений на то, что я хочу сделать, но ни один из них не соответствует тому, что мне нужно выполнить. Я пытаюсь придумать свою структуру для категорий с использованием 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) в качестве внешнего ключа?

Или это хорошая идея сохранить (размер) или (размер) прямо в таблице элементов?

Это было просто для меня, когда я начинал, но чем больше я смотрю на него, тем больше я запутываюсь относительно правильного способа структурирования этого, я хочу, чтобы он работал хорошо для производительности, поскольку это может стать большой объем применения. Но не все ли этого желают?

+0

Результат, который я ищу, заключается в том, что пользователи будут вводить элементы в свои собственные списки, используя выбор категории, а затем могут выбирать прямые атрибуты элемента, соответствующие категории товара. Также пользователи смогут искать в базе данных элементы, используя категории или имена элементов или пользователей, и просматривать результаты элементов с категорией и атрибутами, входящими в этот элемент. –

ответ

0

попытаться понять нормализация сначала. Вот хороший article для вас.

+0

Да, я получаю нормализацию, в прошлом году я взял класс дизайна базы данных, чтобы лучше понять, но то, что я застрял, пытаясь понять, я знаю, что вторичные атрибуты являются непосредственно и только частью каждого точного элемента из таблицы элементов где мои пользователи будут вводить продукты.Мне нужно знать, какие типы суб-атрибутов применяются к каждому продукту в зависимости от категории, в которую помещается элемент. –

+0

@JerrodSand, рад это слышать. Какой именно результат вы хотите? – Haminteu