<div>простой случай - упорядоченность по одному полю. навскидку:</div><div><br></div><div>например, если поддерживается ANSI SQL в части подзапросов с условиями:</div><div>select * from #{table} where #{filters} and #{ordered_field} < (select #{ordered_field} from #{table} where id = #{id}) order by #{order} limit 1;</div>
<div><br></div><div>при необходимости переписывается в объединение.</div><div><div>select tf.* from #{table} tid inner join #{table} tf on tf.#{ordered_field} < tid.#{ordered_field} where <a href="http://tid.id">tid.id</a> = #{id} and #{tf.filters} order by #{tf.order} limit 1;</div>
</div><div><br></div><div><br><div class="gmail_quote">31 октября 2011 г. 1:06 пользователь Mons Anderson <span dir="ltr"><<a href="mailto:mons@rambler-co.ru">mons@rambler-co.ru</a>></span> написал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">Все сразу это может быть ~ 14M записей.<div>давайте все-таки конкретные примеры решений. "через подзапрос" или "через объединение" это не ответ.</div><div><div></div><div class="h5">
<div><br><div><div>On 29.10.2011, at 17:23, Akzhan Abdulin wrote:</div><br><blockquote type="cite">Ну это тривиально. Например, через подзапрос. А можно через объединение. Можно все вместе сразу вытащить.<br><br><div class="gmail_quote">
29 октября 2011 г. 15:27 пользователь Mons Anderson <span dir="ltr"><<a href="mailto:mons@rambler-co.ru" target="_blank">mons@rambler-co.ru</a>></span> написал:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Задача:<br>
<br>
1. Есть некий сложный resultset (joins, filters, order by).<br>
2. Есть id одной строки, который заведомо входит в этот resultset.<br>
нужно выбрать еще 2 строки: ту, которая идет перед этим id и после него.<br>
<br>
Пример псевдозапроса, генерируемого resultset'ом:<br>
select * from photos join users join likes where photo.access > 2 and photo.album = 10 order by likes desc, <a href="http://photo.id/" target="_blank">photo.id</a> asc<br>
<br>
Попробуйте ее решить.<br>
В понедельник кину более детальный пример с решением и объяснением.<br>
<div><div></div><div><br>
On 29.10.2011, at 12:12, Евгений Торопов wrote:<br>
<br>
> Патч интересно было бы посмотреть, да, а вот про пред/след - че-то не понял я, почему via DBIC можно модифицировать запрос, а via DBI / sql-генератор нет<br>
><br>
> On Oct 29, 2011, at 3:52 AM, Mons Anderson wrote:<br>
><br>
>> Кстати мы с vovkasm патчили Class::Accessor::Grouped по аналогии с Class::XSaccessor.<br>
>> Ускоряло работу DBIC в несколько раз.<br>
>> так что в итоге производительность вполне приближалась к DBI.<br>
>><br>
>> Кстати еще в тему DBIC:<br>
>> у нас на проекте есть десятки различных выборок. некоторые делаются из одной таблицы с разными join'ами и разными условиями, некоторые из другой, но к ней join'ится первая таблица.<br>
>> так вот нам понадобилось сделать запрос, который выбрал бы предыдущий и следующий элемент из текущей выборки (resultset'a), относительно текущего.<br>
>><br>
>> используя DBIC эта задача была вполне решаема, т.к. весь запрос представлен в виде объекта и параметров и мы можем полностью проанализировать из чего он состоит и модифицировать его.<br>
>> В случае использования raw DBI на N выборок пришлось бы писать 2N запросов на предыдущий/следующий элемент. И при модификации одного из запросов менять соответственно другие 2.<br>
>><br>
>> Так что при том, что DBIC это оверхед - это порой вполне оправданый оверхед.<br>
>> Хотя я не спорю с тем, что на каких-то highload проектах мы отказыаваемся от DBIC в пользу чистого DBI.<br>
>> Хотя на стадии прототипизации DBIC вполне приемлем т.к. сильно упрощает разработку.<br>
>><br>
>> On 28.10.2011, at 15:59, Peter Rabbitson wrote:<br>
>><br>
>>> On Fri, Oct 28, 2011 at 01:51:00PM +0200, Andrei wrote:<br>
>>>> 28 октября 2011 г. 13:35 пользователь Евгений Торопов <<a href="mailto:jt@aaanet.ru" target="_blank">jt@aaanet.ru</a>>написал:<br>
>>>><br>
>>>>> On Oct 28, 2011, at 3:11 PM, Andrei wrote:<br>
>>>>><br>
>>>>> 28 октября 2011 г. 13:08 пользователь Ivan Petrov <<a href="mailto:i.petro.77.00@gmail.com" target="_blank">i.petro.77.00@gmail.com</a><br>
>>>>>> написал:<br>
>>>>><br>
>>>>>>> Твой аргумент какой то дикий - разница м/у DBIC и писать ручками SQL<br>
>>>>>>> подобна той между Perl и писать ручками assembler. Тебе Perl часом не<br>
>>>>>>> мешает?<br>
>>>>>><br>
>>>>>> неуместное сравнение.<br>
>>>>>><br>
>>>>>> говорить о DBIC vs писать SQL ручками вообще нельзя. ибо DBIC умеет<br>
>>>>>> составлять только самые простые запросы.<br>
>>>>>><br>
>>>>>> а на реальных задачах получаются либо извращения (вроде специальные<br>
>>>>>> VIEW'ы дабы DBIC в них смотрел и не пытался самостоятельничать), либо<br>
>>>>>> те же запросы ручками<br>
>>>>>><br>
>>>>><br>
>>>>><br>
>>>>> DBIC автоматизиреут наиболее частые простые задачи.<br>
>>>>><br>
>>>>><br>
>>>>> Наиболее частые простые задачи автоматизируются примитивнейшими<br>
>>>>> sql-генераторами и не стоят того, чтоб иметь пиздец какой оверхед (<br>
>>>>> <a href="http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html" target="_blank">http://blogs.perl.org/users/aevar_arnfjor_bjarmason/2010/03/benchmarking-dbixclass-vs-plain-dbi-on-hailo.html</a> ).<br>


>>>>> Если бенчмарки по ссылке устарели - покажите новые.<br>
>>>>><br>
>>>>><br>
>>>> Вы бы Айвара до конца читали. А там написано:<br>
>>>><br>
>>><br>
>>> А зачем мне его читать, когда я с ним лично говорил пока он замеры проводил :)<br>
>>> Я ктому ответил что "Да, у DBIC узких мест полно, о них знаем, над ними<br>
>>> работаем и если надо прямо чтоб сегодня быстро - надо так (->cursor)"<br>
>>><br>
>>> --<br>
>>> Moscow.pm mailing list<br>
>>> <a href="mailto:moscow-pm@pm.org" target="_blank">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/" target="_blank">http://moscow.pm.org</a><br>
>><br>
>> --<br>
>> Moscow.pm mailing list<br>
>> <a href="mailto:moscow-pm@pm.org" target="_blank">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/" target="_blank">http://moscow.pm.org</a><br>
><br>
> --<br>
> Moscow.pm mailing list<br>
> <a href="mailto:moscow-pm@pm.org" target="_blank">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/" target="_blank">http://moscow.pm.org</a><br>
<br>
--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org" target="_blank">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org/" target="_blank">http://moscow.pm.org</a><br>
</div></div></blockquote></div><br>
-- <br>Moscow.pm mailing list<br><a href="mailto:moscow-pm@pm.org" target="_blank">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br></blockquote></div><br></div></div></div>
</div><br>--<br>
Moscow.pm mailing list<br>
<a href="mailto:moscow-pm@pm.org">moscow-pm@pm.org</a> | <a href="http://moscow.pm.org" target="_blank">http://moscow.pm.org</a><br>
<br></blockquote></div><br></div>