Здравствуйте, Banch, Вы писали: B>эх, как жаль ... (( B>может они не знают что эта штука очень нужна? ее ж сделать — раз плюнуть!
Как неоднократно обсуждалось ранее, неэффективная реализация подобной фичи силами клиентского приложения — раз плюнуть. Более того, типичная реализация этой фичи в (к примеру) ADO.NET — катастрофически неэффективна. У меня складывается такое впечатление, что команда разработчиков MS SQL считает, что встраивание неэффективного способа бороться с данной фичей в сервер убьет все попытки сделать эффективный клиентский код — слишком велико будет искушение сделать select offset 1000000 top 10 и удивляться, почему среднее время выборки 1 записи составляет 10 секунд. При этом команда разработчиков ADO.NET (на которую молча надеется SQL Server Team), похоже, пребывает в приятном заблуждении относительно реалий жизни.
Разработчика, знакомый с потрошками SQL Server, ничуть не пугает перспектива использовать предикат с никой селективностью — ничего, я сделаю top 10, и поскольку все эти операции можно конвейеризовать, лишних чтений не будет.
Однажды я посмотрел, как MS Access открывает внешнюю табличку с полуторыми миллионами записей. Быстро! Они делают это быстро! Я отпрофилировал этих ребят. О да, разработчики Access не зря едят свой хлеб. Они читают перфичные ключи, а потом скармливают их по мере необходимости в специально подготовленную хранимую процедуру. Причем переход на последнюю страницу вызывает select top 10 .. order by key desc — и это самое быстрое, что можно сделать. Угадайте, что сделает ADO.NET, если пользователь смотрит на первую страницу и переходит на последнюю? Упс, мы поднимаем все полтора миллиона в память IIS, выбрасываем из них первые полтора миллиона и выводим последние 10. Gosh! Ain't they stupid?
Мораль: реализация эффективного постраничного вывода — не раз плюнуть. Я, честно говоря, не испытываю ровно никакой проблемы от отсутствия offset в MS SQL. Равно как и от отсутствия нумерации строк. Если мне нужно быстрое и грязное решение проблемы постраничного вывода — Ok, я пишу select top 100010 и выбрасываю первые 100000. По крайней мере, я знаю, что сервер будет тормозить. А если я хочу построить приложение, которое будет нормально жить и через пять лет эксплуатации, я делаю постраничный вывод эффективно, используя свои знания семантики данных и информацию о действиях пользователя, которая доступна только на уровне клиентского кода.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Banch, Вы писали:
B>т.е. чтобы после постраничного запроса можно было сделать что-нть типо select TOTAL_ROWS, а не делать второй с count(*) запрос как это приходиться делать сейчас всегда
Как ты себе это представляешь? Это требование означает, что сервер в процессе пейджинга, должен каждый раз обрабатывать все записи входящие в выборку, а не только те, которые надо отобразить (идеальный случай), что плохо совместимо с требованиями производительности.
B>все пользователи этих маленьких/средьних серверов смеються над монстрами Oracle/MS в которых есть всякие супер хитрые, полезные и нужные вещи до которым им еще расти и расти, но такой простоты нет
А странным не кажется, что как раз такие монстры, такую фигню не реализовали?
B>я так представляю, что постраничный доступ стал популярен во времена веба, а когда создавались монстры об этом не думали, но почему-то так и не добавили
Ну да, веб сервера в СУБД встроили, а о постраничном выводе не подумали, бывает же...
B>5. сервер может применять оптимизации: B>- оценить что надо выбрать где-то в районе конца и инвертировать сортировку
Ну допустим, хотя тоже задачка не тривиальная.
B>- позволять создавать специальные индексы, помогающие таким выборкам
Как ты себе этот индекс представляешь? За долгие годы для БД ничего лучше различных вариаций B-tree не придумали, за исключением нарошных случаев, к которым пейджинг не относится.
B>и это только на мой взгляд пользователя БД, если спросить у профи, который знает потроха сервера, он наверняка подкинет еще несколько вариантов оптимизации
Как уже неоднократно говорилось, для того чтобы подкинуть варианты оптимизации нужно знать не потроха сервера, а логику работы конкретного приложения.
Мы уже победили, просто это еще не так заметно...
Re: Новые возможности MS SQL Server 9 “Yukon”. Интеграция с
От:
Аноним
Дата:
13.02.04 13:43
Оценка:
Здравствуйте, Антон Злыгостев (Sinclair), Вы писали:
АЗS>Статья:
АЗS>Авторы: АЗS> Антон Злыгостев (Sinclair)
АЗS>Аннотация: АЗS>В статье кратко рассмотрены основные нововведения в MS SQL Server 9.0 "Yukon", связанные с поддержкой разработки серверной логики на .NET.
Позвольте спросить за что подобного рода "статьи" получают столько баллов. Читатели что ознакомились со статьей? Вдруг там полная ерунда написана. Я очень уважаю Sinclair и всегда с интересом читаю его постинги, но все равно не понятно за что ставить оценки на оглавление статьи.
Re: Новые возможности MS SQL Server 9 “Yukon”. Интеграция с
Здравствуйте, Антон Злыгостев (Sinclair), Вы писали:
Спасибо за статью. Но возникли вопросы.
1. Пользовательскими данными могут быть только классы (Value типы ни ни)???
2. Есть ли возмлжность использования Юконом компараторы для десериализованным объектам и создания индексов по ним. (IsByteOrdered понятно)
3. "К счастью встроенные скалярные типы а так же их массивы являются блиттируемыми"
Но массивы в Net ссылочные или данный вариант обходится???
4. Если возможность получать доступ к БД из сериализованного объекта путем передачи есму SqlContext.GetCommand().
и солнце б утром не вставало, когда бы не было меня
Re[2]: Новые возможности MS SQL Server 9 “Yukon”. Интеграция
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Антон Злыгостев (Sinclair), Вы писали:
S>Спасибо за статью. Но возникли вопросы. S>1. Пользовательскими данными могут быть только классы (Value типы ни ни)???
struct тоже можно S>2. Есть ли возмлжность использования Юконом компараторы для десериализованным объектам и создания индексов по ним. (IsByteOrdered понятно)
я так понял, что пока нельзя. Можно ли будет это делать в дальнейшем — неясно. Я бы не рассчитывал на это до выхода десятки. S>3. "К счастью встроенные скалярные типы а так же их массивы являются блиттируемыми" S>Но массивы в Net ссылочные или данный вариант обходится???
Упс. Я поверил в то, что написано в разделе Blittable and Non-blittable types MSDN. На самом деле использовать массивы внутри типов с нативным хранением нельзя. S>4. Если возможность получать доступ к БД из сериализованного объекта путем передачи есму SqlContext.GetCommand().
Вопрос интересный. Скорее всего да, пока не получается потестировать.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Новые возможности MS SQL Server 9 “Yukon”. Интеграция
От:
Аноним
Дата:
06.02.04 08:14
Оценка:
А есть ли документация на Юкон ? на msdn что-то только статьи ...
Re[4]: Новые возможности MS SQL Server 9 “Yukon”. Интеграция
Здравствуйте, <Аноним>, Вы писали:
А>А есть ли документация на Юкон ? на msdn что-то только статьи ...
Она идет вместе с Yukon, а поскольку сам он публично недоступен, то и документация там же. Именно поэтому мы выпустили №6 — чтобы российские программисты могли получить представление о том, что их ожидает в ближайшем будущем. В скором времени Yukon и Whidbey должны поступить в beta-тестирование. Если хотите поучаствовать, то нужно пойти на http://beta.microsoft.com и да пребудет с вами великая сила! А так — рекомендую регулярно посещать http://msdn.microsoft.com/sqlserver/ и следить за новостями.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: Новые возможности MS SQL Server 9 “Yukon”. Интеграция
Здравствуйте, Аноним, Вы писали:
А>А есть ли документация на Юкон ? на msdn что-то только статьи ...
Официально нет. Даже тот BOL, что идет в поставке пре-бэтты, урезан до невозможности, половины глав просто нет. Некоторые примеры с ошибками, часть "...subject to change", и так далее...
Видимо только-только сели писать..
P. S.
от модератора: Здесь принято отвечать после цитаты и удалять избыточное цитирование — M.
Здравствуйте, Banch, Вы писали:
B>если нет, то может как-нть по новому и проще ее можно будет делать?
SELECT * FROM
(SELECT TOP (@PageSize) * FROM
(SELECT TOP (@Page * @PageSize + @PageSize) * FROM sys.objects
ORDER BY name ASC) SO1
ORDER BY name DESC) SO2
ORDER BY name
Здравствуйте, Sinclair, Вы писали:
S>Причем переход на последнюю страницу вызывает select top 10 .. order by key desc — и это самое быстрое, что можно сделать.
При наличии сортировки по ключю. А если его нет? S> Угадайте, что сделает ADO.NET ... Gosh! Ain't they stupid?
Тормозно, но будет работать всегда. А как переделают ? S>Я, честно говоря, не испытываю ... я пишу select top 100010 и выбрасываю первые 100000.
А другие испытавают, возможно. Вероятно в общем варианте серверу всё равно придётся перебирать все записи 100010, но вот выбрасываю первые 100000 лучше б 'говорил' сервер, а не клиент, трафик страдает же. S>По крайней мере, я знаю, что сервер будет тормозить.
И это помогает лучше управлять своим ПО ? S>А если я хочу построить приложение ... которая доступна только на уровне клиентского кода.
Пишешь rset("ADODB.Recordset") или rset("ADODB.Recordset.2.5") ?
и для придирки : тогда пользоваться можно всегда ODBC.
эх ... а у меня задача написать независимый от базы уровень доступа к данным с поддержкой постраничного вывода, при этом кроме текста запроса и параметров этот уровень ни о чем не подозревает
я конечно понимаю, что MS даже не представляет что бывают другие сервера баз данных (достаточно взглянуть на название неймспейса в .Net System.Data.SqlClient, хотя правильнее было бы Microsoft.SqlServer.Client), но
считаю все-таки, что сделать постраничный вывод может только сам сервер
1 — ему не надо никуда передавать первые Н записей или держать какие-то курсоры, ожидая пока клиент удосужиться их промотать
2 — он может реально вообще не выбирать эти Н записей, сделать тоже, что и Аксесс, отсортировать только ключи и выбрать по ним нужное
3 — использовать еще какие-нть оптимизации на основе информации о смещении
а если уж все равно все будет тормозить, то это дело разработчиков клиентских прог, не допускать случаев, когда нужна 100000 страница
так же как такой разработчик может влегкую заставить тормозить сервер, если не будут сделаны соответствующие индексы
так совсем не просто когда нужно обработать произвольный запрос
придется писать парсер SQL и пересобирать запрос
кроме того не уверен, что это сильно эффективный вариан для сервера
получается что каждый способ постраничного вывода приходиться затачивать под конкретный случай запроса
Здравствуйте, Banch, Вы писали:
B>получается что каждый способ постраничного вывода приходиться затачивать под конкретный случай запроса
Об чем и речь. Собственно Синклер это и написал.
Действительно эффективный постраничный вывод можно сделать только зная, что именно из себя представляют пользовательские данные. Поэтому такую функциональность и не вводят, есть гораздо более нужные вещи, которые, к сожалению пока не реализованы.
Лично для меня, в данном случае, не составляет никаких проблем набрать лишних пять строчек кода, срок службы клавиатуры не сильно уменьшится.
Здравствуйте, Banch, Вы писали:
B>эх ... а у меня задача написать независимый от базы уровень доступа к данным с поддержкой постраничного вывода, при этом кроме текста запроса и параметров этот уровень ни о чем не подозревает
Если уровень действительно должен быть от базы не зависим, то и о тексте запроса он знать не должен, иначе о сколь-либо эффективной работе можно забыть.
B>3 — использовать еще какие-нть оптимизации на основе информации о смещении
Смещении чего относительно чего? В том-то и фокус..
Здравствуйте, KGP, Вы писали:
KGP>Здравствуйте, Sinclair, Вы писали:
S>>Причем переход на последнюю страницу вызывает select top 10 .. order by key desc — и это самое быстрое, что можно сделать. KGP>При наличии сортировки по ключю. А если его нет?
Тогда Top вообще не имеет смысла. По очевидным причинам. KGP>Тормозно, но будет работать всегда. А как переделают ?
Кого переделают? KGP>А другие испытавают, возможно. Вероятно в общем варианте серверу всё равно придётся перебирать все записи 100010, но вот выбрасываю первые 100000 лучше б 'говорил' сервер, а не клиент, трафик страдает же.
Я имею в виду Re[2]: вопрос по новым возможностям
. S>>По крайней мере, я знаю, что сервер будет тормозить. KGP>И это помогает лучше управлять своим ПО ?
Ну естественно. Я вижу где у меня теряется производительность. И мне не надо выполнять мучительное профилирование закрытого библотечного кода в попытках понять, куда девается перформанс. S>>А если я хочу построить приложение ... которая доступна только на уровне клиентского кода. KGP>Пишешь rset("ADODB.Recordset") или rset("ADODB.Recordset.2.5") ?
Ну например. А что? KGP>и для придирки : тогда пользоваться можно всегда ODBC.
А при чем тут это? Можно просто не пользоваться фичами, которые ADO.NET предоставляет.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Banch, Вы писали:
B>я конечно понимаю, что MS даже не представляет что бывают другие сервера баз данных (достаточно взглянуть на название неймспейса в .Net System.Data.SqlClient, хотя правильнее было бы Microsoft.SqlServer.Client), но
А как же тогда объяснить System.Data.OleDb, System.Data.Odbc и тем более System.Data.OracleClient
предлагаю System.Data.MSSqlClient B>считаю все-таки, что сделать постраничный вывод может только сам сервер
согласен. B>1 — ему не надо никуда передавать первые Н записей или держать какие-то курсоры, ожидая пока клиент удосужиться их промотать
в любом случае поскипать первые 10000 может не отдавая на такие курсоры, как forward only/
Здравствуйте, Sinclair, Вы писали:
S>Тогда Top вообще не имеет смысла. По очевидным причинам.
Я вёл речь о том, что если запрос отсортирован по имеющемуся КЛЮЧЮ, а не полям, то поскипать сервер первые 10000 може ОЧЕНЬ БЫСТРО, особенно если размер ключевых полей фискирован. S>Кого переделают?
Тормозной вариант ADO.NET S>Ну например. А что?
так rset("ADODB.Recordset") или rset("ADODB.Recordset.2.5") S>А при чем тут это? Можно просто не пользоваться фичами, которые ADO.NET предоставляет.
Тем более глючными .
Просто ADO можно тоже считать наворотом в сравнении с ODBC. Ну про это замнем
Здравствуйте, KGP, Вы писали: KGP>Я вёл речь о том, что если запрос отсортирован по имеющемуся КЛЮЧЮ, а не полям, то поскипать сервер первые 10000 може ОЧЕНЬ БЫСТРО, особенно если размер ключевых полей фискирован.
А-а, ты про это. Я-то имел в виду, что порядок отбора — любой. здесь key — это произвольная комбинация колонок выходного набора данных. На самом деле, падение поизводительности от offset будет даже в случае совпадения сортировки с ключом B-tree индекса. И фиксированность размера ключа никакого отношения к этому не имеет. Если бы мы искали по значению ключа, то у нас был бы шанс выполнить range seek, а у него накладные расходы — o(log(N)). (Расходы на собственно выборку K удовлетворяющих записей я не учитываю). Но мы ищем по номеру! Это означает, что придется выполнять полноценное сканирование индекса и подсчет ключей.
Еще бы я хотел заметить, что даже выражения типа
select offset 1000 top 10 from simpletable where Y=8 order by ID
ОЧЕНЬ БЫСТРО выполнить нельзя. (предполагаем индекс по ID). Потому, что несмотря на сортировку по ключу, есть еще и условие на Y, которое вынуждает сервер честно просканировать как минимум 1010 записей (возможно, выполняя bookmark lookup). В этом случае выполнение
select top 10 from simpletable where Y=8 order by ID desc
для выборки последней страницы на порядок эффективнее — придется просканировать меньше записей.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
И так имея сортировку по ключю ...
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. сервер может применять оптимизации:
— оценить что надо выбрать где-то в районе конца и инвертировать сортировку
— позволять создавать специальные индексы, помогающие таким выборкам
и это только на мой взгляд пользователя БД, если спросить у профи, который знает потроха сервера, он наверняка подкинет еще несколько вариантов оптимизации
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 не готов и на половину и многих вещей там просто нет.
Здравствуйте, Аноним, Вы писали:
А>Позвольте спросить за что подобного рода "статьи" получают столько баллов. Читатели что ознакомились со статьей? Вдруг там полная ерунда написана. Я очень уважаю 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 нумерует записи до сортировки, а значит при использовании напрямую получится полная фигня.
Здравствуйте, Антон Злыгостев (Sinclair), Вы писали: АЗS>Аннотация: АЗS>В статье кратко рассмотрены основные нововведения в MS SQL Server 9.0 "Yukon", связанные с поддержкой разработки серверной логики на .NET.
Вот и прошло то всего 5 лет. Насколько статья актуально, или пора уже новую писать?
и солнце б утром не вставало, когда бы не было меня
Re[2]: Новые возможности MS SQL Server 9 “Yukon”. Интеграция
Здравствуйте, Serginio1, Вы писали: АЗS>>В статье кратко рассмотрены основные нововведения в MS SQL Server 9.0 "Yukon", связанные с поддержкой разработки серверной логики на .NET. S>Вот и прошло то всего 5 лет. Насколько статья актуально, или пора уже новую писать?
Давно пора писать новую. Материал статьи устарел еще в 2005, когда сервер, собственно, вышел. Потому как писалась она по мотивам сырой беты, и в финале многие детали поменялись. Насколько я помню, на современном SqlServer ни один пример из статьи не заработает.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: Новые возможности MS SQL Server 9 “Yukon”. Интеграция
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали: АЗS>>>В статье кратко рассмотрены основные нововведения в MS SQL Server 9.0 "Yukon", связанные с поддержкой разработки серверной логики на .NET. S>>Вот и прошло то всего 5 лет. Насколько статья актуально, или пора уже новую писать? S>Давно пора писать новую. Материал статьи устарел еще в 2005, когда сервер, собственно, вышел. Потому как писалась она по мотивам сырой беты, и в финале многие детали поменялись. Насколько я помню, на современном SqlServer ни один пример из статьи не заработает.
Давненько ты статей не писал. Не ужто тема неинтересная?
и солнце б утром не вставало, когда бы не было меня
((
Мы уже победили, просто это еще не так заметно...
.
