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

Question

Я перерабатываю интерфейс и базу данных для базы данных продуктов среднего размера, чтобы она могла поддерживать категории / подкатегории, линейки продуктов, производителей, поддерживаемое программное обеспечение и атрибуты продуктов.Прямо сейчас есть только таблица продуктов.Там будут страницы для продуктов по линиям, по категориям / подкатегориям, по производителям, поддерживаемым программным обеспечением (необязательно).Каждая страница будет иметь дополнительную фильтрацию на основе других классификаций.

Категории / подкатегории (многоуровневые) Продукты и линейки продуктов могут быть назначены нескольким деревьям категорий.Поддерживается до 5 уровней.

Линии продуктов (одноуровневые) Группы продуктов.Продукт может быть только в одной линейке продуктов.

Производители (один уровень) Продукты и линейки продуктов могут быть назначены одному производителю.

Поддерживаемое программное обеспечение (один уровень) Некоторые продукты работают только с одним илибольше программ, поэтому продукт / линейка могут быть назначены ни одному, одному или нескольким программам.

Атрибуты (тип / опции - можно обрабатывать, чтобы каждый тип был категорией, а элементы - дочерними). ​​Продукты и линейки продуктов могутбыть назначены атрибуты (например, - цвет> красный / синий / зеленый).Атрибуты должны иметь возможность присваиваться одной или нескольким категориям.

Поскольку все эти элементы в основном являются типами подкатегорий, я должен поместить их все вместе в основную таблицу ИЛИ разделить их на отдельные таблицы для каждой?

Идея мастер-таблицы:

ClassificationTypes (линейка продуктов, категория / подраздел, производитель, программное обеспечение, атрибут будут все типы)-TypeID-Имя

Классификации-ID класса-TypeID-ParentClassID-Имя

КлассификацияПродукцияАссоциации-Код товара-ClassID

Мне все еще понадобится хотя бы еще одна таблица для связи типов (например, для связи атрибутов с категорией) и способ связать линии продуктов с различными типами.

Если яиспользуйте таблицу для каждого типа, она может быстро запутаться, и мне все равно понадобится способ связать все вместе.

Настройка нескольких таблиц:

Категории-CategoryID-Название-ParentCategoryID

КатегорииАссоциации-CategoryID-Код товара-ProductLineID?

Атрибуты-AttributeID-Название-ParentAttributeID (используйте это, поскольку родительский будет "color", а child будет "red")

AttributesAssociations-AttributeID-Код товара-CategoryID (мне также нужно связать категорию с родительским атрибутом?)

CompatibleSoftware-SoftwareID-Имя

Совместимое программное обеспечение Ассоциации-SoftwareID-Код товара-ProductLineID?

Производители-ManufacturerID-Имя

ProductLines-ProductLineID-ManufacturerID-Имя

Продукты-Код товара-ProductLineID-ManufacturerID-Name

Другой вариант для ассоциаций - иметь одну таблицу связей, чтобы связать таблицы выше:

Основные ассоциации-Код товара-ProductLineID-ManufacturerID-CategoryID-SoftwareID-AttributeID

Какое лучшее решение?

Answer 1

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

Answer 2

Просто хотел опубликовать свое решение, и так как я не был удовлетворен ни одним из предоставленных ответов, я решил ответить на свой собственный вопрос.

В итоге я создал единый набор таблиц:

Типы классификаций (например, линейки продуктов, категории, производители и т. Д.)

Классификации (поддержка списка смежности родителей / потомков, вложенных наборов и материализованного пути одновременно, чтобы использовать преимущества сильных сторонкаждый. У меня есть SQL CTE, который может заполнить все поля за один раз при изменении данных)

Отношения классификаций (с возможностью связать продукты с классификациями, связать классификации с другими классификациями, а также связать классификации с другими типами)

Я признаю, что решение не нормализовано на 100%, но эта настройка дает мне максимальную гибкость при расширении за счет создания новых типов и является очень мощной и простой в запросе.

Answer 3

Я думаю, что несколько таблиц - это путь, но, чтобы действительно знать, сделайте это: уточните дизайн для обоих способов, а затем возьмите образец из 5-10 продуктов.

Заполните таблицы в обеих схемах для 5-10 продуктов.

Теперь начните писать запросы обоими способами.Вы начнете видеть, что легче написать (одну таблицу, на которую я держу пари), и вы можете найти случаи, которые работают только в одном дизайне (я делаю ставку на несколько таблиц).не потерял работу - вы можете использовать схему таблиц для продвижения вперед, и некоторые ваши запросы уже будут написаны.

Если вы попадаете на запрос, который не имеет смысла, кажется сложным или тому подобным, вы можете опубликовать его здесь и получить обратную связь - реальный код всегда дает лучшие комментарии.

Answer 4

Я согласен с Пэдди. Это облегчит вашу жизнь в будущем, и вы будете более гибкими. Возможно, вы захотите поставить на склад контроль и другие вещи. Чтобы связать все вместе, используйте идентификатор (целое число) parent / child таблиц.