Тимофей

А как это, собственно, можно сделать по-другому? Все правильно в вопросе написано. Можно только еще добавить для удобства scope, добавляющий в запрос колонку с ценами, чтобы все это более прозрачно смотрелось.

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

Ну, если необходимость использования БД возникла на сайтах, которые написаны на PHP, то учи PHP)
Аналогично можно сказать про любой другой язык. БД сама по себе никаким образом не связана с языком программирования. Почти у каждого языка есть библиотеки, которые позволяют работать с БД. Да и сами эти БД бывают разные.

Я, конечно, могу ошибаться, но я думаю, что по нормализации в принципе не так много информации, чтобы учебник читать. Достаточно гугла и запроса "бд нормальные формы". Далее статья в википедии, осознание, что без примеров сложно, поиск и нахождение примеров, опять википедия while (!understood). В принципе можно сказать, что understood == true тогда, когда есть понимание хотя бы первых 3-х нормальных форм. Остальное сложнее для понимания, но при этом достигается само собой в большинстве прикладных задач проектирования БД.

Точно именно декартово произведение? Тогда должно вернуться 6 строк, но это если бы не было условия ON, у тебя же оно есть и составлено вроде бы правильно.
У тебя тут по идее должно вернуться 3 строки, по одной на каждый найденный image. Данные будут дублироваться в данном случае только для pluginid = 1, так как там 2 картинки, и это нормально. Чтобы этого избежать, можно добавить GROUP BY jp.id и SELECT GROUP_CONCAT(ji.image SEPARATOR ',') as images, тогда у тебя вернется строка с картинками через запятую и количество строк на выходе будет равным количеству plugins.