Ну это тривиально. Например, через подзапрос. А можно через объединение. Можно все вместе сразу вытащить.
29 октября 2011 г. 15:27 пользователь Mons Anderson <[email protected]>написал: > Задача: > > 1. Есть некий сложный resultset (joins, filters, order by). > 2. Есть id одной строки, который заведомо входит в этот resultset. > нужно выбрать еще 2 строки: ту, которая идет перед этим id и после него. > > Пример псевдозапроса, генерируемого resultset'ом: > select * from photos join users join likes where photo.access > 2 and > photo.album = 10 order by likes desc, photo.id asc > > Попробуйте ее решить. > В понедельник кину более детальный пример с решением и объяснением. > > On 29.10.2011, at 12:12, Евгений Торопов wrote: > > > Патч интересно было бы посмотреть, да, а вот про пред/след - че-то не > понял я, почему via DBIC можно модифицировать запрос, а via DBI / > sql-генератор нет > > > > On Oct 29, 2011, at 3:52 AM, Mons Anderson wrote: > > > >> Кстати мы с vovkasm патчили Class::Accessor::Grouped по аналогии с > Class::XSaccessor. > >> Ускоряло работу DBIC в несколько раз. > >> так что в итоге производительность вполне приближалась к DBI. > >> > >> Кстати еще в тему DBIC: > >> у нас на проекте есть десятки различных выборок. некоторые делаются из > одной таблицы с разными join'ами и разными условиями, некоторые из другой, > но к ней join'ится первая таблица. > >> так вот нам понадобилось сделать запрос, который выбрал бы предыдущий и > следующий элемент из текущей выборки (resultset'a), относительно текущего. > >> > >> используя DBIC эта задача была вполне решаема, т.к. весь запрос > представлен в виде объекта и параметров и мы можем полностью > проанализировать из чего он состоит и модифицировать его. > >> В случае использования raw DBI на N выборок пришлось бы писать 2N > запросов на предыдущий/следующий элемент. И при модификации одного из > запросов менять соответственно другие 2. > >> > >> Так что при том, что DBIC это оверхед - это порой вполне оправданый > оверхед. > >> Хотя я не спорю с тем, что на каких-то highload проектах мы > отказыаваемся от DBIC в пользу чистого DBI. > >> Хотя на стадии прототипизации DBIC вполне приемлем т.к. сильно упрощает > разработку. > >> > >> On 28.10.2011, at 15:59, Peter Rabbitson wrote: > >> > >>> On Fri, Oct 28, 2011 at 01:51:00PM +0200, Andrei wrote: > >>>> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <[email protected] > >написал: > >>>> > >>>>> On Oct 28, 2011, at 3:11 PM, Andrei wrote: > >>>>> > >>>>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov < > [email protected] > >>>>>> написал: > >>>>> > >>>>>>> Твой аргумент какой то дикий - разница м/у DBIC и писать ручками > SQL > >>>>>>> подобна той между Perl и писать ручками assembler. Тебе Perl часом > не > >>>>>>> мешает? > >>>>>> > >>>>>> неуместное сравнение. > >>>>>> > >>>>>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет > >>>>>> составлять только самые простые запросы. > >>>>>> > >>>>>> а на реальных задачах получаются либо извращения (вроде специальные > >>>>>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), > либо > >>>>>> те же запросы ручками > >>>>>> > >>>>> > >>>>> > >>>>> DBIC автоматизиреут наиболее частые простые задачи. > >>>>> > >>>>> > >>>>> Наиболее частые простые задачи автоматизируются примитивнейшими > >>>>> sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед ( > >>>>> > http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html). > >>>>> Если бенчмарки по ссылке устарели - покажите новые. > >>>>> > >>>>> > >>>> Вы бы Айвара до конца читали. А там написано: > >>>> > >>> > >>> А зачем мне его читать, когда я с ним лично говорил пока он замеры > проводил :) > >>> Я ктому ответил что "Да, у DBIC узких мест полно, о них знаем, над ними > >>> работаем и если надо прямо чтоб сегодня быстро - надо так (->cursor)" > >>> > >>> -- > >>> Moscow.pm mailing list > >>> [email protected] | http://moscow.pm.org > >> > >> -- > >> Moscow.pm mailing list > >> [email protected] | http://moscow.pm.org > > > > -- > > Moscow.pm mailing list > > [email protected] | http://moscow.pm.org > > -- > Moscow.pm mailing list > [email protected] | http://moscow.pm.org >
-- Moscow.pm mailing list [email protected] | http://moscow.pm.org
