[Moscow.pm] Размышления на тему HTML и вообще

[Mons Anderson]

Задача:

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 пользователь Евгений Торопов <jt на aaanet.ru>написал:
>>>> 
>>>>> On Oct 28, 2011, at 3:11 PM, Andrei wrote:
>>>>> 
>>>>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <i.petro.77.00 на gmail.com
>>>>>> написал:
>>>>> 
>>>>>>> Твой аргумент какой то дикий - разница м/у 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
>>> moscow-pm на pm.org | http://moscow.pm.org
>> 
>> -- 
>> Moscow.pm mailing list
>> moscow-pm на pm.org | http://moscow.pm.org
> 
> -- 
> Moscow.pm mailing list
> moscow-pm на pm.org | http://moscow.pm.org