ок, давай возьмем простой пример. список клиентов. Возможные фильтры: наличие заказов одного или нескольких типов, дата последнего заказа не раньше/позднее ххх, закупал ли товары определенных категорий и производителей.
ну и на каждый "фильтр" - свой запрос, какие проблемы? я не вижу принципиальной разницы в данном случае между "формированием фильтра" и "формированием запроса". вот если нужно выбирать ещё и фирмы с этими фильтрами, менеджеров с теми же фильтрами и тп, то имхо стоит сделать это подзапросом (выбрать идентификаторы товаров по условиям, а потом выбрать то что нужно по идентификаторам и условиям)... подзапросы тут лучше в том смысле, что результатирующая таблица будет содержать именно список клиентов и больше никакого мусора.
мы друг друга не понимаем. )) выведи табличку 40 клиентов по фильтру с несколькими такими параметрами.
[sql]select * from clients where (...) and id in ( select client_id from goods where (...)) ) limit 40 [/sql]
в лучшем случае мускул преобразует сам вложенный запрос в left join, в худшем - который неизбежно наступит при увеличении сложности условия, - плюнет на индекс и пойдет перебором по clients и в цикле гонять вложенный запрос. В отдельных случаях я заранее выношу список ид в массив и вставляю его в запрос, но боюсь так могу выйти за пределы длины запроса. Допустим адрес like '%ая%' where cl_descr like '%".$name."%' and id in(select o_cl_id from orders, brends where o_brend=brend.id and brend.name like '%".$name."%') найти туда же какие товары берут еще и т.п. нет времени пока выуживать конкретные варианты, когда мускул начинает тупить и идет перебором, обязательно до этого доберусь, но не сейчас, пока просто обхожу или откладываю. В общем случае вложенные запросы не рулез и пока их можно не использовать, надо это делать. найти всю инфу можно и запросом в цикле, а вот сначала отобрать нужных клиентов - вопрос.
но это другая задача, ее отдельно обсуждать. тут вопрос был - как стоит формировать запрос и передавать классу.
armadillo Глубочайшее имхо, но аргумент "это будет тормозить" - не аргумент при выборе стиля программирования. Программу надо писать так, чтобы она в первую очередь была простой и понятной, во вторую - быстро работала. (Еще более глубочайшее имхо: узкие места в системе - не недостаток, а потенциальная возможность улучшить сайт за счет заказчика )
со вторым не согласен, заказчика надо раскручивать на функционал, а не исправление своего же. но это третья тема. первая: запросы мускула, напишу в том разделе. вторая: способ формирование запроса, это тут. разбираем 1) $sql="select ..."; 2) предельный случай: updateTable(_CLIENTS_TBL,$_POST['clients'],$cl_id);
интересную тему вы здесь подняли.. но я полагаю что необходимо ваще отойти от SQL запросов, в различных частях системы... чтоб модули и другие участки системы даже и не знали что такое SQL. и реализовывать это стоит на РНР5, где больше возможностей в ООП. Что скажете, уважаемые знатоки?
Это что вы такое сморозили!? То-есть выбирать все данные сразу где-нибудь в ядре, а потом модулями разгребать? Изврат.
Hight, это он про ORM говорит... Другое дело, что для PHP это удовольствие слишком дорогое... да и реализаций приличных я не видел.
жесть Жалко hight.fatal.ru не работает, я бы туда сейчас готовую версию класса залил. Или это у меня только оно не работает? А то сегодня какие-то проблемы с интернетом.
Hight Горбунов Олег Если уж на то пошло, то, о чем говорит kogan - это DBAL, а не ORM. ORM - это по определению всего лишь запихивание результатов выборки в поля объектов, и само по себе полезно как мертвому припарки
Одним словом - изврат. Надеюсь не дайдём мы в PHP до уровня когда программы будем создавать передвигая иконки по экрану и рисуя связи между ними. Ничего против абстракции не имею, в некоторых случаях её можно применять, но гибкость подобных решений оставляет желать лучшего.
Hight Ну а мы здесь на что? Программисты для того и учатся, чтобы не просто тупо кодить проекты, а придумывать новые решения. Если решение получается гибким и удобным - замечательно. Если нет - это не повод все сворачивать
Вот не надо ля-ля безосновательно! Корректный ORM - это связывание обьектов данных заданием правил отношений между ними, завязанное на релятивную БД. А вот точно оно часто реализованно как - это другой вопрос.
Горбунов Олег Это называется Active Record. ORM никаких отношений между объектами не подразумевает - это обертывание записи классом, и ничего более.
lexa Это уже не ORM точнее, ORM, но "свой собственный". Напоминаю что ORM в оригинале = Object-Relational Mapping. Остаюсь при своей точке зрения.
Факт в том, что все эти ORM и прочая лабуда в PHP как мёртвому припарки т.к. PHP слишком медлителен и ресурсоёмок, что бы его нагружать такими вещами. Опять же, напомню принцип PHP - KISS - Keep It Simpe Stupid!