Здравствуйте, Антон Злыгостев (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>эх, как жаль ... (( 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 * 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 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Мы уже победили, просто это еще не так заметно...
.