[РЕШЕНО] Типы материалов и поля.

Главные вкладки

Аватар пользователя Uzmediaidea Uzmediaidea 16 июля 2015 в 7:07

Здравствуйте Уважаемые. Подскажите пожалуйста. Как будет правильнее создать структуру для сайта "Каталога товаров".
Пример:

Каталог товаров
Словарь таксономии: Каталог
Термин таксономии:
-Категория 1 для тип материала "Одежда"
--Под категория 1.1 (без полей)
--Под категория 1.2 (без полей)
--Под категория 1.3 (без полей)
-Категория 2 для тип материала "Авто"
--Под категория 2.1 (без полей)
--Под категория 2.2 (без полей)
--Под категория 2.3 (без полей)

Типы материала:
Одежда - (определенные поля для данного типа - 20 полей)
Авто - (определенные поля для данного типа - 10 полей)
и т.д. - (определенные поля для данного типа - 30 полей)

Возможно ли такая структура?

Посоветуйте. Как будет лучше?

Комментарии

Аватар пользователя t1mm1 t1mm1 16 июля 2015 в 11:32

Я делал так.
Search API, views, facet api, taxonomy.
Но в вашем случае нужно делать не в одном словаре.А разбивать - отдельно для одежды, отдельно для авто.
Далее. Вы создаете два разных типа контента.
Единственное, если у вас по терминам будет вложенность - почитайте в одной из моих тем, как я патчил фасеты, что бы при выборке дочернего элемента не учитывало родителя (потому что выбирало только по родителю).
А почитать как делать каталог с помощь фасетов и серч апи можно тут - http://xandeadx.ru/blog/drupal/238

Аватар пользователя Uzmediaidea Uzmediaidea 16 июля 2015 в 13:37

Если будет предположительно 10 типов материала и в каждом типе по 15 полей в среднем. Ни чего страшного?
Нагрузки не будет существенной?

Аватар пользователя t1mm1 t1mm1 16 июля 2015 в 14:39

Встречный вопрос.
А зачем 10 типов - настолько есть существенные отличия?

Вообще, это не страшно.
Друпал при адекватном администрировании справляется и с 50ю типами. Это на производительность не повлияет. Как и количество полей. Исключение - если только вы везде будете пихать entity_load или node_load.
На производительность влияет уже не верная архитектура и велосипеды. Ну и избыточность выгружаемых данных. А количество полей.. 10 - это не много. Это даже мало. Есть пример работы с проектом, где 5 контент тайпов было, и в каждом до 40ка полей. Но с оптимизацией переписали на кастомные составные поля. Кстати, если вы из Харькова - завтра буду в ДКафе с докладом по этой теме.

А вообще не парьтесь. Проекты с данными на 15-20 млн записей - в этом ничего пугающего нет. Пугают только кривые руки.