Всех с Новым Годом Интересуют варианты как можно реализовать подбор характеристик товара как на я.маркет, вот пример http://market.yandex.ua/guru.xml?CMD=-R ... hid=723087
Ну ет само собой, я имею ввиду как бы мне хранить эти данные, чтоб потом можно было сдеть подбор характеристик для категории, и желательно чтоб это был универсальный метод (чтоб не точить БД под конкретную категорию)
Что значит как хранить данные? Ничего нового не придумано. Точить БД таки придется. Все данные по которым нужен поиск должны быть в виде полей таблицы. Для описательных данных можешь сделать поля DESC1, DESC2, ...., DESCN Думаю, около 10-20 хватит на любой объект. Более расширенное атрибутирование можешь сделать при помощи EAV, но сам поиск и работа с этим будет зело неудобна в сравнении с обычными таблицами. Можешь сделать гибрид - основные свойства в полях, как я сказал, расширенные в таблицах EAV.
Чую что там 100% можно обойтись без заточки БД под каждую категорию, надо всего лишь найти способ как это все прописать и разделить.... ток вот хотелось бы заценить уже рабочий способ чтоб потом на камни не попасть...
Верной дорогой идете товарищи (с) один человек с лысиной Продолжайте "чуять" и "заценивать", вместо того, чтобы читать то, что вам пишут. Вы обязательно попадете, туда куда не хотите.
Просто способ с Полный боян, все делается намного проще есть две таблички к примерку категория товара с текстовым полем и вторая табличка уже с самим товаром в категорию пишем примерно так Процессор::Оперативная память::Корпус Atom 330::2 Gb::2U Потом все спокойно парсим...
Да ну. Если у него там десять товаров в списке, почему б не сделать так? А если не десять, то значит те, кто заказал у него эту работу заплатят за свою жадность. Апофеоз справедливости, и спорить и доказывать никому ничего не надо
Есть у нас 3 свойства со статусом есть/нет. хранится это все как Код (Text): ...::есть::есть::нет ...::есть::нет::нет будем набирать полную строку поиска с учетом позиционности? вида: Код (Text): LIKE ...::%::есть::% LIKE ...::есть::%::нет Зело некошерно. А если добавится новое свойство для какого-то одного предмета? Будем апдейтить все записи, дабы сохранить структуру? Или будем переписывать все запросы поиска? Вариант с парсингом может пройти, для хранения нескольких id (которые, по-определению, уникальны) в строке. А это... Да, ну, нахрен. Пусть долбится об этот бред.
если характеристик по поиску много и они все могут быть объектом поиска, я бы хранил данные в json-пакованном виде в innodb-таблицах для управления и в memory-таблицах для выборок. но, памяти понадобится порядочно)))
скажу боян, но в LegkoShop оно реализовано... Динамический каталог с любым кол-вом характеристик http://www.php.ru/forum/viewtopic.php?t=17288
Гоните, товарищи. Делается таблица товаров, делается таблица фильтров, и делается таблица значений фильтров. К примеру, фильтр "Размер", значения фильтра - "большой", "маленький", "сердний" и т.п. И делается еще одна таблица связей товаров и значений фильтров. Таким образом к одному товару можно подключить безграничное количество значений фильтров. Для листинга товаров вытягиваете все связи, потом по полученным айдишкам вытягиваете все товары, значения фильтров и сами фильтры. Ну и там примененные фильтры, доступные товары по фильтрам и все такое.
Что-то ты навернул неудобоваримое для чтения-понимания. большой/маленький/средний - это фильтр для чего? Вот есть у меня два товара: автомобиль и фалоимитатор у автомобиля длина в метрах, у фалоимитатора в сантиметрах. Ну задал я искать "большой" и чего мне должно найти по твоему методу? Приколист однако.... Ты бы не выдумывал велосипеды... То что ты хочешь сделать с "значениями фильтров" - называется справочниками. Плюс EAV для хранения произвольного набора свойств у объекта. Обо всем этом ты можешь прочитать во 2м моем сообщении в данном топике.
Из нас двоих тупит только один человек - тот кто апнул тему. Там показывается внутренняя структура БД? Где? Жгешь однако.