Здравствуйте, Sinclair, Вы писали:

И так имея сортировку по ключю ...
1) сервер сканирует и передаёт данные 10010 записи. Клиент получая 10010 записей скипует 10000 и обробатывает 10.
2) сервер сканирует и 10010 и передаёт данные 10 записей. Клиент получает только 10 записей.

кстати, вспомнил пару вещей

1. поддержка постраничного доступа предполагает еще чтобы можно было легко получить количество всех записей
т.е. чтобы после постраничного запроса можно было сделать что-нть типо select TOTAL_ROWS, а не делать второй с count(*) запрос как это приходиться делать сейчас всегда

2. в .Net есть забавная вещь — якобы встроенная поддержка посттраничного доступа:
SqlDataAdapter.Fill( dataSet, startRecord, maxRecords, srcTable )
но действует она очень смешно — скачивает ВЕСЬ запрос на клиента и выбирает нужное
даже не пытается промотать курсор, как это раньше можно было сделать в ADO, там просто нет move!
такая вот забота о производительности
а потом они пишут вот это чтобы рассказать как ее улучшать

а потом еще ...

3. постраничный доступ реализован в MySql/Postgres/Firebird и всем от этого счастье
все пользователи этих маленьких/средьних серверов смеються над монстрами Oracle/MS в которых есть всякие супер хитрые, полезные и нужные вещи до которым им еще расти и расти, но такой простоты нет
я так представляю, что постраничный доступ стал популярен во времена веба, а когда создавались монстры об этом не думали, но почему-то так и не добавили

и по поводу возражений:

4. пользоваться такой штукой будет удобно до жути
согласен, что при прокрутке 1млн записей могут быть тормоза, но в этом буду виноват я, как и во многих других вещах связаных с производительностью
не зря существует куча хинтов как ее ускорить, это как-раз и есть описание пределов стандартных методов
Но сила стандартных методов именно в том, что они проходят на ура в подавляющем количестве случаев

5. сервер может применять оптимизации:
— оценить что надо выбрать где-то в районе конца и инвертировать сортировку
— позволять создавать специальные индексы, помогающие таким выборкам
и это только на мой взгляд пользователя БД, если спросить у профи, который знает потроха сервера, он наверняка подкинет еще несколько вариантов оптимизации

Здравствуйте, Banch, Вы писали:

B>т.е. чтобы после постраничного запроса можно было сделать что-нть типо select TOTAL_ROWS, а не делать второй с count(*) запрос как это приходиться делать сейчас всегда
Как ты себе это представляешь? Это требование означает, что сервер в процессе пейджинга, должен каждый раз обрабатывать все записи входящие в выборку, а не только те, которые надо отобразить (идеальный случай), что плохо совместимо с требованиями производительности.

B>все пользователи этих маленьких/средьних серверов смеються над монстрами Oracle/MS в которых есть всякие супер хитрые, полезные и нужные вещи до которым им еще расти и расти, но такой простоты нет
А странным не кажется, что как раз такие монстры, такую фигню не реализовали?

B>я так представляю, что постраничный доступ стал популярен во времена веба, а когда создавались монстры об этом не думали, но почему-то так и не добавили
Ну да, веб сервера в СУБД встроили, а о постраничном выводе не подумали, бывает же...

B>5. сервер может применять оптимизации:
B>- оценить что надо выбрать где-то в районе конца и инвертировать сортировку
Ну допустим, хотя тоже задачка не тривиальная.

B>- позволять создавать специальные индексы, помогающие таким выборкам
Как ты себе этот индекс представляешь? За долгие годы для БД ничего лучше различных вариаций B-tree не придумали, за исключением нарошных случаев, к которым пейджинг не относится.

B>и это только на мой взгляд пользователя БД, если спросить у профи, который знает потроха сервера, он наверняка подкинет еще несколько вариантов оптимизации
Как уже неоднократно говорилось, для того чтобы подкинуть варианты оптимизации нужно знать не потроха сервера, а логику работы конкретного приложения.

B>>т.е. чтобы после постраничного запроса можно было сделать что-нть типо select TOTAL_ROWS, а не делать второй с count(*) запрос как это приходиться делать сейчас всегда
M>Как ты себе это представляешь? Это требование означает, что сервер в процессе пейджинга, должен каждый раз обрабатывать все записи входящие в выборку, а не только те, которые надо отобразить (идеальный случай), что плохо совместимо с требованиями производительности.

сделать 2 запроса будет быстрее??

B>>все пользователи этих маленьких/средьних серверов смеються над монстрами Oracle/MS в которых есть всякие супер хитрые, полезные и нужные вещи до которым им еще расти и расти, но такой простоты нет
M>А странным не кажется, что как раз такие монстры, такую фигню не реализовали?

действительно странно
учитывая, что в упомянутых серверах _никаких_ проблем с производительностью постраничного вывода нет!
да и в MS их кстати нет
попробуй на ADO сделать recordset.Move( NumRecords )

B>>я так представляю, что постраничный доступ стал популярен во времена веба, а когда создавались монстры об этом не думали, но почему-то так и не добавили
M>Ну да, веб сервера в СУБД встроили, а о постраничном выводе не подумали, бывает же...

иногда создается впечатление, что в их головах сложилась такая ситуация: раз мы весь нижний уровень реализовали, то давай наворачивать что-нть серьезное, высокоуровневое ...
а если что-то забыли, ну и фиг, все равно дешевле это не доделывать

такая, например, ситуация с обновлением LOB полей в Оракл
у всех это сделать просто, а у них нужно навернуть нехило всяких нестандартных команд

Здравствуйте, Banch, Вы писали:

B>сделать 2 запроса будет быстрее??
Не исключено. К тому же, если совсем припрет, уж count(*) то хранить между запросами страниц, даже в web- приложении, особых проблем не составляет.

B>учитывая, что в упомянутых серверах _никаких_ проблем с производительностью постраничного вывода нет!
B>да и в MS их кстати нет
Так потому и нет, что руками все делается, с нужной степенью добросовестности.

На самом деле, возможно, с появлением Юкона какой-никакой автоматический пейджинг таки появится. То ли в самом Юконе, то ли в ADO.net 2.0, то ли и там и там. Кажется проскакивали какие-то намеки в документации или народ из MS что-то такое говорил, но в каком это будет виде и как это будет выглядеть — понятия не имею, а посмотреть руки не доходят. К тому же новый BOL не готов и на половину и многих вещей там просто нет.

M>На самом деле, возможно, с появлением Юкона какой-никакой автоматический пейджинг таки появится.

будем надеяться

Здравствуйте, Антон Злыгостев (Sinclair), Вы писали:

АЗS>Статья:

АЗS>Авторы:
АЗS> Антон Злыгостев (Sinclair)

АЗS>Аннотация:
АЗS>В статье кратко рассмотрены основные нововведения в MS SQL Server 9.0 "Yukon", связанные с поддержкой разработки серверной логики на .NET.

Позвольте спросить за что подобного рода "статьи" получают столько баллов. Читатели что ознакомились со статьей? Вдруг там полная ерунда написана. Я очень уважаю Sinclair и всегда с интересом читаю его постинги, но все равно не понятно за что ставить оценки на оглавление статьи.

Здравствуйте, Аноним, Вы писали:

А>Позвольте спросить за что подобного рода "статьи" получают столько баллов. Читатели что ознакомились со статьей? Вдруг там полная ерунда написана. Я очень уважаю Sinclair и всегда с интересом читаю его постинги, но все равно не понятно за что ставить оценки на оглавление статьи.

Вероятно, эти люди уже ознакомились с полной версией статьи, напрмер, в бумажном номере RSDN?

Здравствуйте, Аноним, Вы писали:

А>Читатели что ознакомились со статьей?
Да. Читатели купили журнал и ознакомились со статьей.

А>Вдруг там полная ерунда написана.
Не ерунда, я проверял..

А> но все равно не понятно за что ставить оценки на оглавление статьи.
Оценка ставится не за оглавление, а за содержание.

Hello, Banch!

B> над монстрами Oracle/MS в которых есть всякие супер хитрые, полезные и
....а разве в Oracle нету rownum ?

select........where (rownum>100000) and (rownum<=100010)
--
[tip] Fix for Outlook Express quoting: http://Arioch.nm.ru/FL/Fidolook_SL.png
E-mail is faked because of spam. the_Arioch@NM.falseDomain.ru

Здравствуйте, Arioch, Вы писали:

A>select........where (rownum>100000) and (rownum<=100010)
Rownum есть, но вот так вот в лоб им воспользоваться не получится, потому что Oracle нумерует записи до сортировки, а значит при использовании напрямую получится полная фигня.

http://www.rsdn.ru/article/db/identity.xml#XSLTSECTION126145120120

Автор(ы): Иван Бодягин
Дата: 07.02.2004
Уникальная идентификация записей в таблице, является практически основой реляционных СУБД. Вообще в реляционной теории предполагается, что если две записи ни чем друг от друга не отличаются, то это явная избыточность, и количество таких записей можно сократить до одной. Собственно вопросам этой самой идентификации, каковых возникает на удивление много, и посвящен этот FAQ.

Здравствуйте, Антон Злыгостев (Sinclair), Вы писали:

АЗS>Статья:

Для создаются триггера на T-SQL существует соответствующий вариант оператора CREATE TRIGGER:

Опечатка похоже.

Здравствуйте, <Аноним>, Вы писали:
А>Опечатка похоже.
Угу. Я ее писал по ночам. Сдавали номер тоже в жуткой спешке. При возможности исправлю. Спасибо.

Здравствуйте, Антон Злыгостев (Sinclair), Вы писали:
АЗS>Аннотация:
АЗS>В статье кратко рассмотрены основные нововведения в MS SQL Server 9.0 "Yukon", связанные с поддержкой разработки серверной логики на .NET.
Вот и прошло то всего 5 лет. Насколько статья актуально, или пора уже новую писать?

Здравствуйте, Serginio1, Вы писали:
АЗS>>В статье кратко рассмотрены основные нововведения в MS SQL Server 9.0 "Yukon", связанные с поддержкой разработки серверной логики на .NET.
S>Вот и прошло то всего 5 лет. Насколько статья актуально, или пора уже новую писать?
Давно пора писать новую. Материал статьи устарел еще в 2005, когда сервер, собственно, вышел. Потому как писалась она по мотивам сырой беты, и в финале многие детали поменялись. Насколько я помню, на современном SqlServer ни один пример из статьи не заработает.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Serginio1, Вы писали:
АЗS>>>В статье кратко рассмотрены основные нововведения в MS SQL Server 9.0 "Yukon", связанные с поддержкой разработки серверной логики на .NET.
S>>Вот и прошло то всего 5 лет. Насколько статья актуально, или пора уже новую писать?
S>Давно пора писать новую. Материал статьи устарел еще в 2005, когда сервер, собственно, вышел. Потому как писалась она по мотивам сырой беты, и в финале многие детали поменялись. Насколько я помню, на современном SqlServer ни один пример из статьи не заработает.
Давненько ты статей не писал. Не ужто тема неинтересная?