[laimas]

на js уже реализует фильтры...)) ибо молод он для php и ajax)

Ну да, а судя по теме он специалист в JS, и написать выборку по фильтрам и сортировку по условиям ему как два пальца ..., в чем вы его упорно поддерживаете?

Мне все равно как он сделает, но если речь идет о некой базе, то это и должна быть СУБД, не надо ее подменять расплывчатыми понятиями ради сомнительных идей. СУБД, это не просто хранение данных, это их сопровождение, что подразумевает большой спектр понятий. Именно данные конкретной СУБД и будут определять дальнейший скелет веб приложения. Но даже не зная, что скрывается за страшной аббревиатурой СУБД, ему никто не мешает задать вопрос относительно ее - как сделать выборку данных по условиям, ответ будет короткий:

SELECT require_fields, filter_keys FROM table WHERE filter_keys=>filter_values ORDER BY filter_sort

СУБД под приложение проектируют так, чтобы данные в ней были оптимизированы, в частности, если по примеру, то производителей лучше хранить в отдельной связанной таблице, как и некоторые характеристики, которые могут распределять изделия описанные в СУБД по неким классам. Тогда запрос дополнится всего лишь вложенным запросом/запросами для объединения таблиц:

SELECT require_fields, filter_keys FROM table_name
LEFT JOIN table_property
join_conditions
WHERE filter_keys=>filter_values ORDER BY filter_sort

где join_conditions условия по равенству полей, по которым происходит объединение данных в запросе. Все остальное это:

require_fields - поля SQL таблицы, которые должны быть всегда отображаться на клиенте не зависимо от параметров фильтра, если такое необходимо,

filter_keys - ключи массива filter параметров фильтра полученного от клиента и определяющие запрашиваемые поля SQL таблицы,

filter_keys=>filter_values - ключи->значения массива filter параметров фильтра определяющие условия выборки, если это необходимо и выбрано,

filter_sort - поля определяющие сортировку результата выборки данных.

Если при этом работать в PDO, то предварительная обработка полей массива filter перед передачей их в запрос не требуется - в качестве полей условий выборки подставляются именованные параметры :filter_key или неименованные (знак вопроса ?), а в качестве данных соответственно ассоциативный массив фильтра (как есть), или только его значения.

Отдать клиенту полученное при этом совсем просто - echo json_encode($pdo->fetchAll()). В случае работы непосредственно с MySQL, что настоятельно не рекомендуется разработчиком, будет добавлена предварительная обработка входных данных (параметров фильтра), а получение массива данных из записей, это цикл while.

И здесь больше моих слов, чем будет символов в реальном коде выборки данных из базы, который даже на средненьком форуме ему покажут. Мои слова ради объяснения того, что все просто. Если есть необходимость работать с базой на клиенте, то и в этом случае нужно работать с базой, а не localStorage в чистом виде, и для этого тоже уже есть готовое, не надо изобретать лисапеда. И только, если данные, это бублики с дырочками или без них, с маком или без него, и бублики будут вечны, можно рассуждать о плюшках, которые легко вписываются в нечто легкое для localStorage. Вот только по ссылке "типа этого" данные ну никак не вписываются в простоту, о которой вы утверждаете, значит вы не понимаете ни как подобные данные организуются, как связываются и как обслуживаются. А автору темы описывать свои конкретные данные, которые как он пишет будут просты до смешного, и забудет о понятие базы, и прописывает их сразу в js-файл объектом, или грузит единожды в localStorage, поступая по личному вкусу. Иначе получается, что ссылаются на серьезные темы, а разговор хрен знает о чем.