| ← Декабрь 2008 → | ||||||
|
1
|
2
|
3
|
4
|
5
|
7
|
|
|---|---|---|---|---|---|---|
|
8
|
9
|
10
|
11
|
12
|
14
|
|
|
15
|
16
|
17
|
18
|
19
|
21
|
|
|
22
|
23
|
24
|
25
|
26
|
28
|
|
|
29
|
30
|
31
|
||||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 222
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)"Выпуск 222 от 27 декабря 2008 г.Новым посетителям сайта Сайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения
состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.
Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 50-й задачи первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов, которые пригодятся на третьем рейтинговом этапе, который начинается после 138 задачи.Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. С наступающим Новым Годом, с новым счастьем!Новости сайта§ С помощью dimaP, orange и MeVit усилил проверку задач 37, 70 и 127 соответственно. § Изменения среди лидеров (решенные за неделю задачи третьего этапа): § Продвинулись в рейтинге: § Новые лица в ТОР 100 и вернувшиеся туда: § На этой неделе сертифицированы: § Число подписчиков - 3834 Число участников рейтинга - 20421 Число участников второго этапа - 1649 Число участников третьего этапа - 45 Сертифицировано на сайте - 345 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQLМассивы и списки в SQL Server 2005 (начало в вып.217-221)Erland Sommarskog (оригинал: Arrays and Lists in SQL Server 2005 )Перевод: Моисеенко С.И. Типы MAX или обычные (n)varchar?В предыдущем разделе я обсуждал проблемы соединения nvarchar с varchar. Когда я запускал свои тесты производительности и исследовал некоторые неожиданные результаты, я обнаружил вторую проблему подобного рода. Посмотрите на это: SELECT ... FROM tbl t JOIN list_to_table(@list) l ON t.indexednvarcharcol = l.nvarcharmaxcol Функция list_to_table (список-в-таблицу), которая используется здесь такова, что возвращаемое значение имеет тип nvarchar (MAX). Это также приводит к неявному преобразованию типа индексного столбца. На первый взгляд это может показаться неочевидным, но когда SQL Server оценивает выражение, он всегда работает с одним и тем же типом данных для всех операндов. И очевидно, что nvarchar(4000) и более короткий отличается от типа данных nvarchar(MAX). Результат неявного преобразования не является фатальным. Оптимизатор применяет оператор поиска в диапазоне (range-seek) и по-прежнему может использовать индекс, но, тем не менее, здесь есть потери производительности. Когда я впервые запускал мои тесты, я не наблюдал этой проблемы, и мои однооператорные функции возвращали nvarchar(MAX) (по той простой причине, что входная строка имела тип nvarchar (MAX)). Как следствие, казалось, что мои тесты в некоторых случаях показывали худшую производительность для однооператорных функций, чем соответствующие решения на базе многооператорных функций. Вероятно, в большинстве случаев, когда Вы используете функции list_to_table для списка строк, последние будут короткими, лишь в несколько символов длиной. Поэтому, есть все основания проверить, что ваша функция list_to_table возвращает обычный varchar или nvarchar. В частности, это означает, что для однооператорных функций Вы должны проверить явное преобразование возвращаемого значения к обычному (n)varchar. Вы сможете увидеть это во всех однострочных функциях данной статьи. Коллации (схемы сопоставления)Все функции в этой статье используют nvarchar как для параметров, так и для выходных и внутренних переменных. Если Вы никогда не работали с данными Unicode, то можете подумать, что Вам следует переписать функции на использование varchar, предполагая, что SQL Server будет быстрей работать с 8-битовые символами, чем с 16-битовыми символами Unicode. Это может быть так или напротив в зависимости от используемой коллации. Как уже обсуждалось при сравнении varchar и nvarchar, есть два типа коллаций: коллации Windows и коллации SQL. Если Вы используете коллации Windows, то получаете незначительное падение производительности при использовании varchar вместо nvarchar. Это происходит из-за того, что при коллациях Windows все правила и процедуры внутри используют Unicode, поэтому всякое использование varchar приводит к некоторым дополнительным преобразованиям. С другой стороны, при использовании коллации SQL Вы можете получить приблизительно 30-ускорение времени выполнения при использовании varchar. Это обусловлено тем, что коллации SQL являются только 8-битовыми, для которых существуют отдельный набор 8-битовых процедур, и правила для 8-битового набора символов намного проще, чем правила для Unicode. Если Вы имеете коллацию SQL и используете nvarchar, Вы фактически внутри используете сопоставление Windows. Следует отметить, что точный прирост производительности зависит от типа операции. 30 % - это то, что Вы можете ожидать от простого сравнения на равенство. Есть ситуации, когда использование varchar или nvarchar для коллации SQL может приводить к разнице в 7 раз. Мы увидим такой случай в разделе "действительно медленных методов". Но есть один вариант для улучшения производительности при работе с nvarchar: используйте двоичную коллацию. Теперь, если Вы решили использовать двоичную коллацию повсюду в вашей базе данных, Вы должны будете принять, что все сравнения нечувствительны к регистру, что сортировка является странноватой, особенно если язык не является английским. Поэтому для большинства приложений, двоичная коллация не приемлема. Однако существует еще одна возможность: применяйте коллацию для отдельного выражения. Я использовал этот прием в статье везде, где это имело смысл. Вы найдете много таких конструкций: charindex(@delimiter COLLATE Slovenian_BIN2, @list, @pos + 1) Так как @delimiter преобразован к явно указанной коллации, это же происходит и с @list. (Данный вопрос обсуждается в Books Online в статье Collation Precedence.) При использовании charindex для поиска разделителя будет лучше искать точный разделитель, и не иметь необходимости в нечувствительном к регистру или акценту поиске. Таким образом, использование двоичной коллации в данной ситуации не приводит к какой-либо потере функциональности. Когда я протестировал это на итерационном методе, то получил приблизительно 10%-ое уменьшение времени выполнения. (Почему Словенская? И почему BIN2? Словенская потому, что мои тестовые данные представляли собой список словенских слов из орфографического словаря. BIN2 - новый тип двоичных коллаций в SQL 2005. Я действительно не почувствовал разницы по отношению к использованию старых двоичных коллаций, но все же, это, наверное, лучший выбор. Так или иначе, не важно, какую двоичную коллацию Вы используете.) (Продолжение следует...) Полезная информация§ Приглашаем вас посетить новый проект - Интерактивный учебник по SQL. § Онлайновый выпуск рассылки можно почитать на сайте. § Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § Хотите поддержать проект? Вот инструкция по применению. :-) КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77[@]yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
| В избранное | ||
