Как правильно организовать хранение продуктов для доски объявлений?

Question

[Тимур Худиев]

Доброго времени суток. Есть задача сделать доску объявлений.

Есть категории:

1. Авто
   
2. Квартиры
   
3. Телефоны
   
4. И т.д...
   

Суть в том что у продуктов могут быть свои характеристики. Например у квартир есть площадь, а у телефонов нет. Или, допустим, у авто есть свойство объем двигателя, тип кузова.

Как правильно организовать хранение продуктов и категорий в базе?

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

Если у кого есть мысли, направьте на правильный путь

Answer 1

[Антон]

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

Comments

[Тимур Худиев]

А вот это мне нравится)

[Тимур Худиев]

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

[Антон]

Тимур Худиев, Другое дело, если для каждого отдельного товара в одной категории могут быть разные характеристики, но и это, по сути, можно решить этой же таблицей и добавить еще одно поле, где тип сущности будет либо объект(товар), либо категория.

[Антон]

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

[Тимур Худиев]

Антон, Понятно. А по поводу предыдущего вашего комментария, что у одной категории может быть несколько характеристик. В таком случае лучше делать для каждой характеристики отдельную запись или просто через разделитель ID характеристики записывать в один столбец?
Это я имею в виду, когда человек будет добавлять новый продукт

[Антон]

Тимур Худиев, Лучше бы отдельными записями, что-то может изменится и, допустим, характеристику "высота" нужно будет для отдельных категорий чем то дополнить, изменить, а что будет в итоге? Правильно, поменяется везде, и чтобы такого не было, пусть лучше будет 10 характеристик "высота" для 10 разных категорий, но они будут "родными", а не общими.
В будущем, что-то еще в характеристиках может поменять, например, для разных категорий будет установлено какое-то дефолтное значение, что-то вроде "ОТ"...много, вообщем, различных вариаций масштабирования данного

Answer 2

[ThunderCat]

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

Answer 3

[Lander]

1. Создаёте таблицу с общими полями для продукта. + поле type
2. На каждый тип продукта создаёте таблицу с полями ТОЛЬКО для этого типа продукта.
3. В зависимости от значения поля type делаете JOIN той или иной таблицы в запросе.