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

[Akzhan Abdulin]

простой случай - упорядоченность по одному полю. навскидку:

например, если поддерживается ANSI SQL в части подзапросов с условиями:
select * from #{table} where #{filters} and #{ordered_field} < (select
#{ordered_field} from #{table} where id = #{id}) order by #{order} limit 1;

при необходимости переписывается в объединение.
select tf.* from #{table} tid inner join #{table} tf on tf.#{ordered_field}
< tid.#{ordered_field} where tid.id = #{id} and #{tf.filters} order by
#{tf.order} limit 1;


31 октября 2011 г. 1:06 пользователь Mons Anderson <mons на rambler-co.ru>написал:

> Все сразу это может быть ~ 14M записей.
> давайте все-таки конкретные примеры решений. "через подзапрос" или "через
> объединение" это не ответ.
>
> On 29.10.2011, at 17:23, Akzhan Abdulin wrote:
>
> Ну это тривиально. Например, через подзапрос. А можно через объединение.
> Можно все вместе сразу вытащить.
>
> 29 октября 2011 г. 15:27 пользователь Mons Anderson <mons на rambler-co.ru>написал:
>
>> Задача:
>>
>> 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 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
>
>
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mail.pm.org/pipermail/moscow-pm/attachments/20111031/e51b2a17/attachment.html>