Добрый день.
Очень хочется узнать мнение компетентной общественности по вопросу организации некоего каталога товаров. Задача, в общем-то, стандартная, но есть вопросы.
Собственно, основной вопрос поста это эффективности работы Field API.

Планируется реализовать некий структурированный каталог товаров на базе node. Структура каталога определяется таксономией.
Все товары имеют некие общие свойства: артикул, дата производства, производитель, страна производства, раздел каталога, фотографии и.т.д.
У некоторых групп товаров могут быть еще и уникальные свойства, например, для мебели это размер, цвет, для сантехники способ монтажа и т.д.

Планируемое количество товаров 20-30 тыс.
Количество терминов таксономии для словаря разделов около 100.
Количество видов товаров, имеющих уникальные свойства 20-30.
Планируемая посещаемость 3-5 тыс.

Главная требование - быстрый и удобный поиск почти по всем возможным параметрам в разделе.

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

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

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

Главная идея в том, чтобы отказаться от Field API для хранения единичных значений и использовать Field API только для тех свойств, которые требуют множественных значений, например, фотографии.
Конечно, нужно будет реализовывать hook_scheme(), hook_node_insert(), hook_node_update() и еще некоторые для управления данными. В итоге получаем всего, как максимум, две основные таблицы: совсем базовая - node, таблицу для хранения общих параметров и еще несколько таблиц для хранения уникальных свойств определенных типов товаров.
Все записи в этих таблицах связаны один к одному, поиск по параметрам осуществляется мгновенно. Можно даже свои индексы определить.
При написании еще еще некоторого количества кода можно эти типы подружить со вьюс, которые хорошо будет использовать для простых списков.

Ну как-то так Покритикуйте пожалуйста.

П.С. Думаю, что наверняка уже когда-то обсуждался подобный вопрос, но найти не смог.