Форум MySQL

Доброго времени суток! В какой-то из веток данного форума я прочел, что в случае с PHP - СУБД частично рушит ООП подход.... Хотелось бы поподробнее про это узнать. Но мой главный вопрос более конкретен... правильное решение или нет?.... Итак.....
Задача.... по выбранным пользователем фильтрам показать список товаров и доступные фильтры для этого списка, чтобы можно было дальше фильтровать.......

Мое решение......
1. SQL - по заданным фильтрам во временную таблицу выбираются id нужных товаров... Например из 40000 в нее попадают 50. и Уже по этим 50 id-кам присоединяются таблицы с описанием, а также таблицы с доступными фильтрами. Получается, что в одной процедуре делается все... и она возвращает несколько результирующих таблиц.

2. В PHP схематично фрагмент кода выгладет так

$query="call procedure ($param1, $param2, $param3 и т..п.);
$connect=dbhandler::SELECT($query);

if (isset($connect[0])){
фетчим список товаров, проверяем результат, делаем concat (напрмиер название, фирма модель) и результирующий массив готов к отправке в контроллер и затем к выводу
}
if (isset($connect[1])){
фетчим список фильтров и т.п.
}

Конечно меня смущает, что в одном методе делается очень много работы, а где-то читал, что методы и классы не должны быть "слишком умными".... и каждый должен заниматься своим делом...... Но.. реально встает вопрос, неужеле надо все дробить на методы или даже классы? Смущает, то, что в итоге все упрется в запуск тяжелой процедуры...... или вообще сделать несколько процедур, типа одна берет товары, другая фильтры, но... поскольку товары завязаны на фильтрах, а фильтры на товарах, то если это разбивать, получиться оооооочень тяжело для sql-сервера........

Как схематично можно решить подобную задачу?

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

>Конечно меня смущает, что в одном методе делается очень много работы
Это как раз не страшно, плохо то, что вы зависите от индексов и фактически от switch(), который замаскирован несколькими if-вызовами. Тут нужен полиморфизм. Однако, СУБД его не поддерживает - она реляционная, а не объектно-ориентированная, поэтому без switch вам не обойтись и это очень плохо, так как в этом месте у вас не будет полиморфизма, а следовательно преимуществ от ООП, а недостатки останутся (малая эффективность, большой объем кода). Там где программист, использующий структурный подход просто использует базу данных, у вас появляется вагон и маленькая тележка работы (перевода одной парадигмы в другую)... взяли в руки ООП - расплачивайтесь, никто не обещал, что он всегда полезен, эффективен и позволяет создавать меньше кода, иногда бывает наоборот...