MySQL много разных свойств объектов

L
На сайте с 03.05.2006
Offline
171
1745

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

Например, насос - размеры, вес, производительность; генератор - размеры, вес, мощность, вид топлива. И так для каждого типа товара разный набор свойств.

Пока есть несколько глупых идей.

1. таблица получится огромная с массой пустого места, которое будет жрать место

CREATE TABLE `products` (

`product_id` int,

`property1` type,

`property2` type,

....

`propertyN` type,

)

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

3.

CREATE TABLE `products` (

`product_id` int,

`properties` text,

)

`properties` - в эту ячейку грузим хэш со всеми параметрами - очень все удобно, но поиск с сортировкой не сделать

Но это все не очень красивые решения.....

А как создать такой каталог?

edogs software
На сайте с 15.12.2005
Offline
719
#1

Определитесь сначала с тем, что это будет за каталог.

Как часто будет появляться новый тип товаров.

Сколько типов товаров сейчас.

Как много товаров.

Как много свойств.

Прочее.

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

Универсальное решение классическое нормальное - таблица товаров, таблица свойств, таблица связей между одним и другим. Но не ждите от этого решения ничего кроме универсальности.

Разработка крупных и средних проектов. Можно с криптой. Разумные цены. Хорошее качество. Адекватный подход.
L
На сайте с 03.05.2006
Offline
171
#2
edogs:
Определитесь сначала с тем, что это будет за каталог.

В качестве примера рассмотрим некий аналог например магазина стройматериалов и стройинструментов.

имеем сотни категорий и в каждой категории сотни товаров. (всего 100,000 товаров)

Ну таки да, изредка категории будут добавляться.

Но на самом деле система должна работать одинаково хорошо и для 100 и для 1000 товаров и/или категорий.

seocore
На сайте с 25.09.2006
Offline
143
#3
luxs:
А как создать такой каталог?
  • основная таблица с базовыми свойствами товаров;
  • таблица рубрик (где указывается id-перечень доп. свойств товаров);
  • таблица дополнительных свойств товаров: id-свойства, название свойства;
  • таблица доп. свойств к базовой таблице товаров: id-товара, id-свойства, значение;
Инструменты для веб-мастера: кластеризатор СЯ (https://goo.gl/MQWfqO), все запросы конкурента (https://goo.gl/hd5uHS), дешевые XML-лимиты (https://goo.gl/aDZbPI)
totamon
На сайте с 12.05.2007
Offline
350
#4
luxs:
А как создать такой каталог?

если сами не понимаете, то можно "подсмотреть" готовые решения, например в Simpla реализован такой каталог с разными свойствами товаров, которые задаются к категориям.

не призываю тупо копировать, но разбираться лучше на примерах))

Хостинг от 90р ( https://goo.gl/h1VRkY ) и ВПС от 161р ( https://goo.gl/vw9JH7 ) 14 дней бесплатный тест! Лучшие ВПС, ТП огонь, все страны! https://8fn.ru/inferno а тут ВПС за 1,25$ https://8fn.ru/vps1doll Монетизация любых сайтов PUSHами ( https://8fn.ru/push ) - лучшая цена клика и показа ;)
ДП
На сайте с 23.11.2009
Offline
190
#5

В общем и целом то, что вам нужно, называется Entity-Attribute-Value EAV - для теоретического ознакомления советую по этому словосочетанию погуглить - как это всё делается и оптимизируется.

[Удален]
#6

Можно просто юзать что-то вроде MongoDB.

Но если подвязаны на что-то вроде MySQL, то да придется повозиться с атрибутами, если по хорошему то еще и с типами этих атрибутов.

L
На сайте с 03.05.2006
Offline
171
#7

Читая всякие форумы, типа stackoverflow, постоянно натыкаюсь на "Don't go with EAV." поэтому и не стал вникать в детали.

Ну а ставить вторую БД типа mongo - выглядит довольно сложным решением по началу.

Попробую посмотреть на "конкурентов"

REBUS
На сайте с 20.02.2003
Offline
109
#8

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

S
На сайте с 23.05.2004
Offline
290
#9

Правильный вариант - держать в двух таблицах, в одной товар, в другой проперти. Будет не устраивать - перейти на тип поля JSON в MySQL. Еще будет не устраивать - перейти на postgresql и HStore . Снова не устраивает , ставим ElasticSearch , загоняем товары в индекс и ищем с абалденной скоростью по любым параметрам.

Это просто мой личный сайт (https://phpdevs.com/) в моей подписи.
L
На сайте с 03.05.2006
Offline
171
#10
REBUS:
А вопрос быстродействия стоит? Просто при большом количестве запросов я бы отталкивался именно от этого, если же нагрузки большой не ожидается делал бы структуру наиболее понятной для человека.

Проблема быстродействия стоит всегда, т.к. не известно заранее количество объектов.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий