И еще советую изучить вопрос: будут ли у вас цены зависеть от атрибутов, и будут ли присутствовать мультиатрибуты. Если ответ положительный, то мой совет все-таки уберкарт.

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

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

Также интересует такой вопрос.
Проблема заключается в том, что магазин продает разную продукцию - Бытовая техника, телевизоры, автомобильная техника и другое.
Выгрузка товара происходит из 1С через csv файл.
Хотелось бы организовать магазин наиболее удобным образом
Так, чтобы была возможность создания удобного каталога, удобных фильтров...

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

Друпал (7) был выбран из-за гибкости.
Commerce по советам в интернете, да и, на сколько я понял, Уберкарт подходит больше к 6 версии (по тем же отзывам)

Commerce на сколько я знаю вообще не знает что такое мультиатрибуты. Могу и ошибаться.

Опыт разработки на Друпал есть, но не магазина таких масштабов.
В основном друпал выбирался из-за гибкости, наличия какого-то опыта и знаний по этой системе, дополнительные идеи по организации работы магазина в далеком и тд ))
Понравился магазин ktc-ua.com (тут где-то ссылка на него выкладывалась уже).
Судя по всему, вопрос по организации продукци и каталогов тут был таким же (поля характеристик для бумаги и ноутбуков отличаются)

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

Загрузка товара и дисплеев идет через feeds.

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

"DanTeS" wrote:

Есть магазин с большим количеством видов товара, которые отличаются по своим характеристикам. например ноутбуки, мышки, карты памяти + стиралиные машины, морозилки и тд
Вопросы:
каким образом лучше организовать product types и product display
сделать 1 тип продукта или 1 дисплей или много продуктов много дисплеев (для каждого типа свое) и тд
каким образом лучше для этого варианта организовать каталог товаров и их вывод (taxonomy views)

"seolyric" wrote:

Это для тебя 5 минут, а для ТС нет!

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

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

Также интересно было бы услышать все же что выбирают лиди - DC или UC. По отзывам я понял, что DC будет набирать обороты.

Т.е. вы считаете купили ЮМИ и проект готов?
Даже при простоте его конфигурирования, придется потратить еще около 50-100к на его настройку и подгонку. Итого от 80 до 130к бублей.

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

И опять таки: в ЮМИ проблема с матрицей атрибутов. Внутри товара вы можете на ЮМИ переключить цвет, вес, материал и чтобы менялась при этом цена?
А если этих атрибутов 10-ки да и у каждого из атрибутов 10-ки опций? Тут кроме уберкарта ничего не поможет, как бы вы не расхваляли другие возможные ЦМС-ки.

И много многое другое что не могут платные движки, но может срупал.

делали - navigator-gr.ru

Вернее, делаем в данный момент.

Для простых уже выбираю DC, для сложных все еще UC.

да, а у других вообще никакой логики на этот счет нет.

Я прекрасно знаю что он перемножает, другого варианта по идее нет. Есть, но я его не скажу
Поэтому я и говорю про матрицу атрибутов.

И Уберкарт прекрасно справляет с такой матрицей 10х10.

"thumper" wrote:

Этот же вопрос интересует.

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

Пока что было несколько вариантов

Product type <-> Product display
1) 1 <-> N
2) N <-> 1 (2,3,4)
3) N <-> N

1й вариант плох тем, что есть всего один тип товара и по одному шаблону грузятся все товары. Есть товары, которые имеют атрибуты типа "цвет", "размер", "диагональ" и тд, которые подходят именно для этого типа товаров, а есть продукты, которые такого вовсе не имеют (например карты памяти). и тогда с хранением таких данных и возникает проблема.
С Характеристиками товара тут особо проблем нету (если это мышка КОМПАНИИ Х, то "цвет на скорость не влияют"

2й вариант более менее интересный. Создать 1 (или пару) дисплеев, в которых бы были включены поля, которые будут показаны для всех товаров (например: "диплей с текстом", "дисплей с текстом и видео",....)
Тут у товара можно хранить и атрибуты и характеристики.
Минус заключается в том, что для одного товара, имеющего разные атрибуты но одинаковые характеристики (мышки разного цвета, "цвет на скорость не влияет"), то в базе придется хранить кучу одинаковой инфы (записи в БД отличаются только атрибутом, но с кучей одинаковых полей по характеристикам).
Еще один минус, это то, что на страничке товара, как я понимаю, при смене атрибута постоянно будут обновлться поля характеристик.

3й вариант неплохо подходит.
Проблема в громоздкости. ну и в удобстве работы.

скопипастил свой пост с другой темы ) В этой как-то все активней обсуждается

Безусловно N <-> N

"divined" wrote:

Безусловно N <-> N

N < - > N тоже привлекает больше всего.
Просто не возникнут ли потом проблемы при создании и настройки вьюх и фильтров?
Не повлияет ли такая громоздкость на работу сайта?

Спасибо большое за советы

"divined" wrote:

Для простых уже выбираю DC, для сложных все еще UC.

Это по меньшей мере странно

Скажите,
есть ли реальный опыт решения поставленной ТС задачи?
Как все-таки лучше организовать хранение характеристик товаров?