2 декабря 2009 в 17:48
Как проще реализовать характеристики товара?
ССК становится очень неудобен, когда их становится сотни и особенно, если часто приходится добавлять новые.
Кроме того:
- Если характеристик много, то таблица в mysql очень сильно расползается, так как каждое поле, это отдельный столбец.
- При добавлении нового поля, приходится выдумывать ему системное имя. Хотя, можно ограничится каким-нибудь att_1, att_2 и так далее, но такое решение не вызывает восторга.
- Я не любитель для каждого типа товара создавать новый тип ноды, что влечет за собой огромное количество полей для ввода при создании ноды, большинство из которых нужны лишь однажды.
- Если все же использовать разные тип ноды, то это влечет за собой другую проблему. Часто у близких по тематике товаров есть много как общих так и различных характеристик. Что опять же, добавляет много лишних полей, много таблиц в базе по каждой из общих характеристик, усложняет поиск и фильтрацию.
Комментарии
дык какая вам разница-то? посетители на сайт ходят или в базу данных? а у вас есть UI
включаем фантазию...
я слышал, сейчас есть специальные модули, которые интуитивно показывают нужные поля, в зависимости от того, о чем вы сейчас думаете
еще используйте conditional fields например
в cck одно поле можно использовать в разный типах, не знали?
на готовом сайте если вас смущает постоянное дерганье базы - настройте файловый кеш, делов-то
Уже был опыт написания каталога с большим количеством полей. Редактировать такую конструкцию ноды (добавить или изменить поле) становится очень проблематично, так как страница в админке начинает весить целую килотонну. Все долго грузится и ужасно лагает. А полей было не так уж и много. Около 100. Сейчас планируется магазин, где различных характеристик будет более 1000.
Забивать номенклатуру буду не я, а девочка, которая печатает двумя указательными пальцами. Ей нужно чтобы на странице были одно поле и одна кнопка «добавить». Чуть сложнее и уже ни за что не разобраться.
Это необходимо для моего душевного спокойствия. Если я буду знать, что под капотом у меня все аккуратно по полочкам разложено и работает так как задумано, то и спать я буду лучше.
Какая фантазия? Нудная монотонная работа.
Та же проблема, когда полей становится очень много полей. И не забывайте про девочку, которая в админке обязательно наломает дров. Система должна быть максимально простой.
Знал и написал, чем мне этот вариант не нравится «много таблиц в базе по каждой из общих характеристик».
для душевного спокойствия поставьте VPS
я имел ввиду что ОДНО единственное поле можно раскидать в разные типы, то есть создали поле "цена" (соответственно создалась в базе таблица) и используете это же поле для типа Карандаши, Тетрадки, Ручки и т.д. куда уж меньше таблиц епт?
и КАК моя дурья башка не может понять, можно доверять девочке заполнять ведомости по товарам, тип данных которых состоит из такого числа полей... девочку на кол, маникюр под гильятину.
я не могу даже придумать, какую тематику можно выдумать, чтобы было до 1к полей в одном типе О_о нужен ли такой магазин вообще?
1000 характеристик по все типам. Например, тот же Кей.
Но я понял вашу позицию. ССК и ни каких компромиссов
я не силен в программировании)
Если я правильно понимаю, о чем речь - то гляньте как это сделано в ubercart attributes.
Можно оставить 1 тип товара, и к нему добавлять необходимые атрибуты. Ну а каждый атрибут имеет некоторое количество опций.
В том модуле опции к атрибутам забиваются отдельно и собсна девочка в админке сможет добавить атрибут, выбрать какие-то его опции и всё.
В вашем случае (обратно если верно понял) вам этот модуль не подойдет, но можно сделать свой, по аналогии.
То бишь в БД 4 таблицы,
mymodyle_attributes (Поля aid, name, label)
mymodule_attribute_options (oid, aid, name, weight)
mymodule_node_attributes (nid, aid, name)
mymodule_node_options (nid, oid, name)
При добавлении ноды выбираем нужные атрибуты, к ним выбираем опции из существующих, или заносим свои.
Но такая структура подойдет в случае если у значений 1000 ваших полей будут какие-то определенные значения, т.е число опций хоть как-то ограничено.
На сколько я помню, attributes в ubercart используется для костумизации товара. Например, если товар может быть нескольких цветов, то чтобы не забивать для каждого из оттенков новую позицию, этот параметр добавляют как опцию, а покупатель уже выбирает из предложенных вариантов.
Мне требуется имено перечисление большого количества характеристик.
Я начал потихоньку писать свой модуль. Думал, может есть уже готовые решения. Не может быть, чтобы с этим ни кто раньше не сталкивался.
Для пятерки был модуль
http://drupal.org/project/taxonomy_fields или http://drupal.org/project/cck_taxonomy - не помню.
в зависимости от выбранного термина - доступны разные наборы полей CCK.
Может я не понял...но что это за товары, у которых более 1000 различных, характеризующих их параметров, которые надо забивать в поля, приведите пример! Просто любопытно, может Вы не туда копаете?
1000 характеристик – это на все виды товаров. А не в каждой ноде по 1к параметров.
Делать для каждой разновидности товара свой тип ноды и добавлять к ней по 20-30 полей мне не нравится.
Например, Кей. Или любой другой магазин, который торгует всем подряд.
на Кей заходят более 30к хостов каждые сутки, вы думаете он пожадничает купить мощный сервер чтобы не переживать за размер и количество таблиц? или поскупится нанять человека с мозгами не 20-летней блондинки? Может все-таки не по Сеньке шапка?
если вам ничего не нравится, почему бы совсем не отказаться от cck, оставьте тип story и пусть себе девочка набирает размер, длина, вес...
в догонку... вы представляете себе структуру таблицы, если лепить в нее все подряд? не боитесь что база тупо этого не выдержит? myisam ведь помоему блокирует записи в которых происходит действие, а inno - не для всех таблиц подходит...
(не спец, могу быть не прав)
Вот что накропал. Извиняюсь за ролик, но, на мой взгялд, так наиболее быстро и наглядно можно донести идею.
В двух словах: для модуля используется две таблицы. С атрибутами и значениями атрибутов. Модуль сверяет названия, и если такой атрибут уже есть, добавляет для него значения в конкретной ноде. Если нет, то сначала создает атрибут, а потом сохраняет для него значение.