Подскажите, на чём реализовать такое?

MySQL, PostgreSQL как и MongoDB умеют работать с JSON объектами и искать по ключам.

Для реализации брать фреймворк и на нем пилить. Все равно все упрется в интерфейс юзера, админку и т.п, а далее по десятку раз переделываться.

Даже если всего всех свойств 50 на все записи, то серфер быстрее закроет страницу, чем заполнит такого размера форму. А если просо искать по вхождению - то это банальный текстовый поиск по полю. А потом выводить и сортировать объекты как душа пожелает.

ortegas,

спасибо! посмотрю ещё, но, похоже, то, что нужно

Stek,

не нужно ничего заполнять, нужно просто реализовать что-то типа продвинутого фильтра. Знаете, наверное, как в магазинах:

1) Показать пылесосы - (показываем)

2) Показать пылесосы Bosch (из конкретной выборки пылесосов) - показываем

3) Показать пылесосы (не Bosch) которые стоят от 5000 до 20000 - показываем

Вот что-то типа такого. Понятное дело, что в админке мне кучу всего заполнять. Но юзеру должно быть удобно: ввёл слово (свойство) и по нажатию на кнопку ему выдались все объекты, содержащие это свойство.

Можно в принципе фильтр сделать, что-то типа такого. Ну идею понятно описал, наверное) что хочется на выходе иметь.

php и get/post-запросы. Можно и куки.

Обычная форма с выводом данных. Какие нафик ВП. Да и БД тут может покурить в сторонке, если речь только о формах.

Перечитал несколько раз и не понял что тут нестандартного. Самый обычный фильтр.

Только не связывайтесь с WP в этом случае.

Есть пример реализации (тысячи товаров с сотнями характеристик с мгновенным откликом), если интересно - в ЛС

самый простой вариант, это сделать две таблицы, в одной - тип объекта и поля идентичные для всех объектов, например название и id

вторая таблица - представляет собой коллекцию уникальных полей для всех элементов

вторая таблица выглядит как

id поля

тип поля

значение поля

id объекта

(прочая служебная информация, как то описание, дата последнего изменения, id изменения для отката и пр)

далее, чтоб выбрать все данные по какому-либо параметру, достаточно будет произвести выборку по ид поля, после чего мы получим все объекты содержащие в себе эти поля.

все в общем то просто.

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

Но как показала практика (мы это делали в 2010м году для каталога сайта "из рук в руки", при правильной настройки индексов падение производительности оказывается мизерным)

ну а по части вывода пользователю, думаю, что оптимально было бы сделать так, как это сделано в старом я.маркете (посмотрите на вебархиве)

silicoid, наверное, 3 таблицы лучше двух:

1. Объекты

2. Свойства

3. Значения свойств объектов

Sitealert, на самом деле так и есть.

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

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

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