Теперь Uzhast.
Цитата:Если у тебя возможность использования ТОЛЬКО SQL-запроса, то не получится. Но ты же имеешь прямой доступ к таблице 1С. Значит, у тебя есть возможность доступа к физическому номеру записи. Так что все выглядит просто:
1) Выбираем N строк с учетом упорядочивания. Для каждой строки запоминаем физический номер.
2) Когда ТП просит M строк с нужной строки, упорядочиваем записи, используя упорядочивающее выражение.
3) Переходим по физическому номеру записи к нужной.
4) Переходим к следующей/предыдущей записи в зависимости от того, в каком направлении двигаемся.
5) Выбираем M строк в нужном направлении.
Ты этот свой "простой" алгоритм кроме своей головы еще гденить пробовал тестить?
У тебя п.2 и п.3 противоречят друг-другу.
Если ты используешь индекс для упорядочивания, то перейти по физическому номеру записи невозможно.
Кроме как full-scan'ом.
Так-что возможный алгоритм мог бы быть такой (для случая выборки следующих строк) :
1. Делаем index seek по ключу.
2. Сканируем по индексу дальше, ища запись с нужным физическим номером.
3. Получаем следующие записи.
Однако этот алгоритм неверен. Во-первых, ключ этой записи уже мог изменится.
(Другой юзер уже переименовал, удалил, перенес в другую группу)
В лучшем случае новый ключ записи больше старого, и рано или поздно, двигаясь
по индкесу, мы до нее дойдем. В худшем - новый ключ меньше, либо отсутствует.
В этом случае вообще ничего не найдем.
Во-вторых, ТП работает не так, как ты себе представляешь - оно не просит
провайдера "получи М строк от текущей записи".
Оно просит "получи первые М строк с ключом БОЛЬШИМ, чем вот этот сохраненный ключ"
Так вот в этом случае, если бы я точно был уверен, что одинаковые ключи в индексе
расположены СТРОГО по порядку номеров физических записей, алгоритм был бы таким:
1. Делаем index seek по переданному ключу.
2. Двигаемся по индексу далее, пока (номер записи меньше переданного и ключ не больше переданного).
3. Как только это условие не выполняется, получаем М строк.
Вот поэтому я и спрашивал, упорядочиваются ли дублирующиеся ключи в индексе ещё и
по физическим номерам записей.
Цитата:Вообще, ИМХО, страсть использовать SQL-запросы для построения курсоров - пагубная.
Для курсоров лучше использовать XBase-подобные средства.
А SQL-запросы в подобных задачах наоборот, вместо наглядности и простоты выборки данных,
дают усложения и лишние тормоза на ровном месте.
Ща я тебе покажу, какая это гадость - курсоры.
Проведем экперимент:
1. Открываем две копии 1С с одной базой, хоть дбф, хоть sql.
2. Открываем в ней форму списка большого справочника.
3. В обоих базах ставим время автообновления 99, и встаем на один и тот же элемент справочника
примерно в середине списка, где-то например, на букве "К".
4. В одной копии меняем название элемента, например, первую букву заменяем на "П".
5. В другой - пытаемся походить вверх/вниз от текущего элемента. Внимательно наблюдаем
за интересными артефактами.
6. Закроем/откроем справочник.
7. Опять встаем на один и тот-же элемент.
8. В одной программе переносим элемент в другую группу.
9. В другой пытаемся походить вверх/вниз от текущего элемента. И не можем этого сделать.
Вот так вот работают курсоры.
И как раз из-за того, что пляшут они от текущей записи, ключ которой может меняться
в других сессиях.
А в ТП с ODBC-поставщиком данных такой хрени не происходит.
И насчет "лишние тормоза на ровном месте" хотелось бы, чтобы ты свое мнение
подтвердил конкретными цифрами и тестами. Если конечно сможешь написать ODBC-поставщика
на серверных курсорах.
А "проскок" N строк в текущей реализации ODBC-поставщика очень даже можно сделать.
select max(key) from (select top N key from lalala where key > storedkey order by key) topNkeys
либо
select top 1 key from (select top N key from lalala where key > storedkey order by key) topNkeys order by key desc
Страницы: [1] 
1sqlite (число прочтений - 64549 )
