| ← Апрель 2009 → | ||||||
|
1
|
2
|
3
|
5
|
|||
|---|---|---|---|---|---|---|
|
6
|
7
|
8
|
9
|
10
|
12
|
|
|
13
|
14
|
15
|
16
|
17
|
19
|
|
|
20
|
21
|
22
|
23
|
24
|
26
|
|
|
27
|
28
|
29
|
30
|
|||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 238
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)"Выпуск 238 от 18 апреля 2009 г.Новым посетителям сайта Сайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения
состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.
Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 49-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов, которые пригодятся на третьем рейтинговом этапе, который начинается после 138 задачи.Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. Новости сайта§ Ростовчан приглашаем посетить семинар, посвященный SQL Server 2008. Там, за облаками. Microsoft SQL Server и концепция приложений в "облаке"Семинар состоится 29 апреля (начало в 16:00) по адресу:ул. Мильчакова 10 (здание НКТБ Пьезоприбор), Факультет высоких технологий ЮФУ, а. 514 (5 этаж)
§ Произошла замена задач 4-6, 50. Старые задачи перешли на обучающий этап. § Добавил подсказки к задачам 5, 55, 118. § На форуме рейтинговых задач открыт новый топик - 800. Здесь вы можете задавать и отвечать на вопросы по SQL, непосредственно не связанные с решением задач на сайте. § Изменения среди лидеров (решенные за неделю задачи третьего этапа): § К третьему этапу подошел (до замены задач): § Продвинулись в рейтинге: § Новые лица в ТОР 100 и вернувшиеся туда: § Продвижение ближайших претендентов на попадание в ТОР 100: § На этой неделе сертифицированы: § Число подписчиков - 3860 Число участников рейтинга - 20283 Число участников второго этапа - 1794 Число участников третьего этапа - 47 Сертифицировано на сайте - 366 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQLМассивы и списки в SQL Server 2005 (окончание, начало в вып.217-229, 231-237)Erland Sommarskog (оригинал: Arrays and Lists in SQL Server 2005 )Перевод: Моисеенко С.И. Однако производительность этой процедуры, как и подобной ей, использующей INSERT VALUES, оставляет желать лучшего. Приличной производительности удается достичь, если мы используем трюк с INSERT-EXEC и большим числом небольших операторов SELECT, предложенный Джимом Эбберсом (Jim Ebbers). Ниже представлена эта процедура, определенно более сложная, чем представленная выше. CREATE PROCEDURE unpack_with_manyselect
@list nvarchar(MAX),
@tbl varchar(30),
@delimiter nchar(1) = ',' AS
DECLARE @sql nvarchar(MAX),
@q1 char(1),
@q2 char(2)
SELECT @q1 = char(39), @q2 = char(39) + char(39)
SELECT @sql = 'INSERT ' + @tbl + ' EXEC(' + @q1 + 'SELECT ' +
replace(replace(@list, @q1 COLLATE Slovenian_BIN2, @q2 + @q2),
@delimiter COLLATE Slovenian_BIN2,
' SELECT ') + @q1 + ')'
--PRINT @sql
EXEC (@sql)
Здесь внутренний replace заменяет одиночную кавычку в @list не менее чем четырьмя одиночными кавычками. Это связано с тем, что сам INSERT EXEC вложен в EXEC(). (Вы могли догадаться, почему у меня там стоит закомментированный PRINT @sql !) В эту процедуру я также добавил предложение COLLATE. (Другая процедура настолько медленна, что COLLATE там не оказывает никакого влияния на производительность.) Если Вы посмотрите более внимательно, то заметите, что представленные процедуры работают пока только с числовыми величинами. Если Вы хотите подавать на вход список строк, то должны сами закавычивать строки. Вот версия для обработки строк: CREATE PROCEDURE unpackstr_with_manyselect
@list nvarchar(MAX),
@tbl varchar(30),
@delimiter nchar(1) = ',' AS
DECLARE @sql nvarchar(MAX),
@q1 char(1),
@q2 char(2)
SELECT @q1 = char(39), @q2 = char(39) + char(39)
SELECT @sql = 'INSERT ' + @tbl +
' EXEC(' + @q1 + 'SELECT ltrim(rtrim(' + @q2 +
replace(replace(@list, @q1 COLLATE Slovenian_BIN2, @q2 + @q2),
@delimiter COLLATE Slovenian_BIN2,
@q2 + ')) SELECT ltrim(rtrim(' + @q2) +
@q2 + '))' + @q1 + ')'
--PRINT @sql
EXEC (@sql)
Пример использования: CREATE PROCEDURE get_company_names_manyselect @custids nvarchar(2000) AS CREATE TABLE #temp (custid nchar(5) NULL) EXEC unpackstr_with_manyselect @custids, '#temp' SELECT C.CompanyName, C.CustomerID FROM Northwind..Customers C JOIN #temp t ON C.CustomerID = t.custid go EXEC get_company_names_manyselect 'ALFKI, BONAP, CACTU, FRANK' Действительно ли этот метод представляет собой хорошую альтернативу для обработки списков с разделителями-запятыми? Нет. Производительность для списков целых чисел сравнима с итерационным методом, но значительно медленнее для списков строк. Итерационный метод имеет преимущество в его легкой адаптации под различные форматы на входе и простом получении дополнительной информация типа позиции в списке. unpack_with_manyselect ничего этого не дает. Его сильная сторона - вставка большого числа значений. Замечание. Все рассмотренные здесь процедуры включают INSERT. Но Вы можете выбросить INSERT из процедуры, и вместо него вызывать процедуру из INSERT EXEC. В этом случае Вы на выбор можете использования либо временные таблицы, либо табличные переменные. Действительно медленные методыВ колонке Q&A журнала SQL journal один SQL Server MVP, обращаясь к другому MVP, предложил следующее решение: CREATE PROCEDURE get_company_names_charindex @customers nvarchar(2000) AS
SELECT CustomerID, CompanyName
FROM Northwind..Customers
WHERE charindex(',' + CustomerID + ',', ',' + @customers + ',') > 0
go
EXEC get_company_names_charindex 'ALFKI,BONAP,CACTU,FRANK'
Вы можете узнать эту тему по нашему использованию таблицы чисел. Добавляя запятые по обеим сторонам входной строки, мы можем использовать charindex, чтобы найти, ",ALFKI," и т.д. (Заметим, что здесь мы не можем иметь вложенных пробелов.) Автор отметил в своей колонке, что этот метод не будет обладать хорошей производительностью, поскольку включение столбца таблицы в выражение препятствует использованию любого индекса на этом столбце, приводя к сканированию таблицы. Но это далеко не все. Простое сканирование таблицы на моей тестовой таблице заняло 800 миллисекунд, когда таблица полностью находится в кэше. Этот метод потребовал 65 секунд для входного списка из 20 строк! Вариации на эту тему иллюстрируются следующими предложениями WHERE: WHERE patindex('%,' + CustomerID + ',%', ',' + @customers + ',') > 0
WHERE ',' + @customers + ',' LIKE '%,' + CustomerID + ',%'
Решение с LIKE так же медленно или даже медленнее, чем charindex. Я никогда не проверял patindex на 2005 SQL. Здесь есть "переключатель скорости ": предложение COLLATE. Добавьте предложение COLLATE для приведения к бинарной коллации, и производительность улучшается в 7-10 раз. Но проблема состоит в том, что, если Вы передаете строку типа alfki,bonap,cactu,frank, то можете все еще ожидать прирост, которого Вы не получили бы с бинарной коллацией. Поэтому в моих тестах, я применял коллацию только тогда, когда на вход подавался список целых чисел, как в этом примере: CREATE PROCEDURE get_product_names_realslow @ids varchar(200) AS
SELECT ProductName, ProductID
FROM Northwind..Products
WHERE charindex(',' + ltrim(str(ProductID)) + ',' COLLATE Slovenian_BIN2,
',' + @ids + ',' COLLATE Slovenian_BIN2) > 0
go
EXEC get_product_names_realslow '9,12,27,37'
Если Вы используете коллацию SQL, Вы также получаете такой же огромный прирост производительности, если можете ограничиться типом varchar (и нечувствительностью к регистру). Но даже при увеличении производительности в 10 раз, мы все еще имеем семь секунд для списка из 20 целых чисел. В то же время любой другой метод потребует не более пятидесяти миллисекунд. ЗаключениеВы познакомились с множеством методов передачи списка значений в SQL Server с последующим использованием этих значений для поиска данных в таблице. Большинство методов преобразовывает список значений в таблицу. Я также высказал общие соображения относительно применения этих методов. Если Вы хотите узнать больше о производительности этих методов, обратитесь к приложению к данной статье, где я представляю данные моих тестов. Полезная информация§ Приглашаем вас посетить новый проект - Интерактивный учебник по SQL. § Онлайновый выпуск рассылки можно почитать на сайте. § Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § Хотите поддержать проект? Вот инструкция по применению. :-) КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77[@]yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
| В избранное | ||
