Задача: 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
