Проектируете базу данных с несколькими видами продуктов?

В рамках недавнего проекта, который я начал планировать, мне нужно создать структуру базы данных, которая будет содержать несколько продуктов. В качестве примера подумайте о том, как устроена Amazon. Он имеет несколько категорий и внутри этих категорий несколько подкатегорий.

Моя проблема в том, что концептуально я не уверен, как создавать таблицы базы данных. Я думал о создании самореферентной таблицы для категорий и подкатегорий, но, поскольку я планирую иметь в базе данных широкий спектр продуктов, я не знаю, следует ли мне просто сгруппировать их в одну таблицу под названием " Товары» или вынести их все в отдельные таблицы.

Например, унитаз может быть одним продуктом, а телевизор — другим. Несмотря на то, что они имеют разные категории/подкатегории, они оба являются продуктами. Поместив их в одну таблицу «Товары», они получили бы общие атрибуты, которые не имели бы смысла для них обоих. Туалету не нужен атрибут разрешения или размера дисплея (если только это не особый туалет?), а телевизору не нужен атрибут размера сиденья.

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

Итак, на данный момент я чувствую, что моя настоящая проблема заключается в том, чтобы выяснить, как структурировать эту базу данных и ее таблицы с несколькими категориями/подкатегориями и различными типами элементов. Создал бы я стол для телевизоров и стол для туалетов? Как это все будет структурировано? Как обычно планируются такого рода проблемы?

Спасибо


person biddano    schedule 27.12.2013    source источник


Ответы (3)


Это больше дизайнерское решение, чем что-либо еще.

Вот как я бы разделил таблицы:

categories (например, домохозяйство)

sub_categories (например, ванная комната является внешним ключом домашнего хозяйства)

products (например, керамический унитаз)

Что касается дополнительных атрибутов, вы можете либо сохранить их непосредственно в таблице продуктов, либо создать другую таблицу с именем products_extra_attributes и сохранить необязательное значение NULL в таблице products, которое будет внешним ключом, указывающим на дополнительные атрибуты для отдельного продукта.

Есть смысл? Я внесу изменения позже, если нет, поскольку я отвечаю на этот вопрос со своего телефона.

person Joel Murphy    schedule 27.12.2013
comment
Хорошо, я думаю, это имеет смысл. Таким образом, у меня будут общие атрибуты для всех продуктов в таблице Products и внешний ключ для другой таблицы ExtraAttributes (названной как-то так), где каждая строка в ExtraAttributes будет иметь свойства для разных продуктов, таких как туалеты или телевизоры. Это звучит правильно? - person biddano; 27.12.2013
comment
Вы поняли :) В зависимости от масштаба вашего каталога продуктов - вам лучше поступать таким образом, поскольку вы будете соединять таблицы только в том случае, если продукт имеет дополнительные атрибуты (определяемые этим дополнительным значением внешнего ключа в таблице продуктов, как вы поняли). - person Joel Murphy; 27.12.2013

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

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

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

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

Вот простая примерная схема:

введите здесь описание изображения

person antony    schedule 27.12.2013
comment
Ницца. Просто наблюдение на вашей схеме. Почему бы не убрать таблицу категорий и не добавить ее свойства (id, parent_id, name) в таблицу category_product? - person fat_mike; 27.07.2017
comment
@fat_mike Приведенная выше схема хорошо работает, когда у вас есть продукты, которые существуют в нескольких категориях. Это также позволяет избежать дублирования данных, например. имя категории каждый раз, когда вы добавляете продукт в категорию (поскольку каждой записи потребуется свойство имени категории). - person antony; 31.07.2017

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

Например, возьмем телевизор Sony. Это будет в продуктах с ценой и ссылкой на тип продукта, который будет ТВ. Это соединит один ко многим атрибуты, которые есть у всех телевизоров, а Sony TV будет иметь записи в значениях продукта для каждого из этих атрибутов. Таким образом, вам не нужно было бы переопределять общие атрибуты, поэтому, когда вы начали продавать другие вещи с разрешением, вы могли бы просто добавить их к типу продукта.

Есть смысл?

person Frank Conry    schedule 27.12.2013