Как в крупных электронных магазинах сделаны поля товаров?

Если я правильно понял о чём ты, это называется нормализация баз данных. Всё лишнее выносится в отдельную таблицу, связь по ключам.

А если несколько разных типов полей? К примеру string и boolean. Если это все будет в одной таблице, например в такой:

ИМЯ ПОЛЯ	ЗНАЧЕНИЕ

Разрешение	1280x1024
Фонарик		true

P.S. Забыл добавить, что речь идет о реляционных БД. В нереляционных с этим попроще.

Как все это дело хранится?

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

Будет замечательно если подскажете как организовать много полей в Drupal.

Конкретизируй.

Будет замечательно если подскажете как организовать много полей в Drupal.

Конкретизируй.

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

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

С этим моментом теперь все ясно, спасибо.

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

фильтр для друпала ищи в каталоге фильтров друпала, не?

Как все это дело хранится?

если ты про друпал - на каждое поле по отдельной таблице с привязкой к ноду по entity_id
вытаскивается всё это через функции работы с данными, так что нет смысла заморачиваться руками с запросами

Будет замечательно если подскажете как организовать много полей в Drupal.

есть два варианта развития:
1 - Набиваешь типы товаров (content type), по одному на тип товара, набиваешь "уникальные" поля в каждый тип товара (уникальные кавычках, ибо большинство полей можно повторно использовать в разных типах товара)
2 - Набиваешь один content type, далешь select со всеми типами товаров, набиваешь все поля из всех типов товаров, по вкусу добавляешь ajax-обработку первого селекта, чтоб лишние поля прятать, иначе едиторы быстро свихунться

и это... ты с друпалм вообще знаком?

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

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

Это все вещи мне знакомы. Еще можно сделать группы полей через Fields Group, тоже ничего получается. Думал может есть что-то получше.

Про хранение полей в друпале знаю. Хотел узнать «как у других», может идея бы пришла какая-нибудь, но видимо лучше и не придумаешь.

Я и не про друпал, а про крупные магазины.

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

В друпал я лезть не собираюсь :) Просто было интересно как это делается в крупных проектах.

Fields Group

это ещё хуже чем мой второй вариант :)

а по теме - я бы делал отдельный content type на каждый тип товара
думаю так было бы проще всего мэнтэйнить, гибкость и всё такое
ну и если всё это будет медленно ворочаться - накинуть кэшей каких нибудь
sqlite на крайняк добавить, он вроде как самый быстрый на чтение

было интересно как это делается в крупных проектах

trashymichael правильно ответил, каждый по своему и "косо криво лишь бы живо" :)

Я немного не так выразился. Там и разные типы товаров со своими полями + еще поля в каждом типе делятся на группы. Так полегче искать хоть.

Было бы здорово какой-нибудь модуль типа Module filter, но для форм.

ну и если всё это будет медленно ворочаться - накинуть кэшей каких нибудь
sqlite на крайняк добавить, он вроде как самый быстрый на чтение

Админю не я, и хостинг обычный shared. Но пока ворочается.
А вот про sqlite не совсем ясно, неужели она быстрее MySQL? Тем более друпал кэши в БД хранит, а у MySQL есть кэш в памяти. С SQLite только если Memcahe использовать, иначе же совсем плохо будет, или нет?

раньше как-то sqlite считал быстрее, щас нагуглил сравнения - на продакшн по любому не советуют ставить, да и по навороченности как ни крути сливает
хотя поиграться было бы интересно, так сказать набрать личный опыт

а вообще да, скорее всего лучше обойтись без нестандартных решений и пойти протоптанной тропой...
memcache, varnish и иже с ними :)