[Moscow.pm] Размышления на тему HTML и вообще
Mons Anderson
mons на rambler-co.ru
Сб Окт 29 04:27:39 PDT 2011
Задача:
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
Подробная информация о списке рассылки Moscow-pm