| ← Апрель 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) 236
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)"Выпуск 236 от 04 апреля 2009 г.Новым посетителям сайта Сайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения
состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.
Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 50-й задачи первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов, которые пригодятся на третьем рейтинговом этапе, который начинается после 138 задачи.Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. Новости сайта§ Добавил подсказку к задаче 89 (второй рейтинговый этап задач на SELECT). § Автор изменил формулировку задачи 153, приняв вариант, предложенный $erges. § На странице с упражнениями обучающего этапа уже появляются ссылки на соответствующие разделы справки. § Изменения среди лидеров (решенные за неделю задачи третьего этапа): § Продвинулись в рейтинге: § Продвижение ближайших претендентов на попадание в ТОР 100: § На этой неделе сертифицированы: § Число подписчиков - 3845 Число участников рейтинга - 19965 Число участников второго этапа - 1772 Число участников третьего этапа - 47 Сертифицировано на сайте - 364 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQLМассивы и списки в SQL Server 2005 (начало в вып.217-229, 231-235)Erland Sommarskog (оригинал: Arrays and Lists in SQL Server 2005 )Перевод: Моисеенко С.И. Динамический SQLДля списка чисел этот метод покажется обманчиво простым: CREATE PROCEDURE get_product_names_exec @ids nvarchar(4000) AS
EXEC('SELECT ProductName, ProductID
FROM Northwind..Products
WHERE ProductID IN (' + @ids + ')')
go
EXEC get_product_names_exec '9, 12, 27, 37'
Но вся история намного более сложна. Есть несколько проблем, которые следует иметь в виду. Для начала давайте рассмотрим пример со списком строк: CREATE PROCEDURE get_company_names_exec @customers nvarchar(2000) AS
EXEC('SELECT CustomerID, CompanyName
FROM Northwind..Customers
WHERE CustomerID IN (' + @customers + ')')
go
EXEC get_company_names_exec '''ALFKI'', ''BONAP'', ''CACTU'', ''FRANK'''
Вложенные кавычки затрудняют вызов процедур, использующих этот метод. Далее следует рассмотреть разрешения. Обычно, когда Вы используете хранимые процедуры, пользователи не должны иметь непосредственный доступ к таблицам, но это правило не применяется, когда Вы используете динамический SQL. В SQL 2000 ничего нельзя было с этим поделать. В SQL 2005 Вы можете организовать разрешения, подписывая процедуру с помощью сертификата. У меня есть отдельная статья, которая описывает, как это сделать - Предоставление Разрешений через Хранимые Процедуры. Но таких сложностей не требует никакой другой метод из рассмотренных в этой статье. Всегда, когда Вы работаете с динамическим SQL, Вам следует помнить об SQL-инъекции. Т.е. если вход непосредственно формируется пользователем, то злонамеренный пользователь может выполнить нерегламентированный код SQL. Об этом особенно стоит заботиться, если ваше веб-приложение предназначено для работы в сети Интернет. SQL-инъекция широко распространенный прием хакеров для неавторизованного проникновения на сайты. Обычный способ избежать SQL-инъекции состоит в том, чтобы использовать параметризованные операторы, но так как число параметров является переменным, здесь это не работает, и Вам придется использовать другие методы, которые более сложны и менее безопасны. Я обсуждаю SQL-инъекцию и другие проблемы динамического SQL в моей статье Проклятье и Благословения Динамического SQL. Когда речь заходит о надежности и гибкости, мы следует заметить, что Вы не можете выбирать разделитель; запятая - единственная возможность. Нет никакого способа получить положение в списке. И Вы можете использовать только встраиваемый метод - нет никакого способа распаковать данные во временную таблицу или табличную переменную. Что касается производительности, это может оказаться самым быстрым методом для вашего запроса. Это единственный метод, когда оптимизатор имеет полную информацию о входе, и это может привести к лучшему плану, чем тот, который строится на основании слепых предположений или статистике временной таблицы. Но все может быть и иначе. Фактически, в моих тестах динамический SQL оказывался одним из самых медленных методов, уступая даже итерационному методу. Причина заключается в том, что для динамического SQL Вы получаете расходы на компиляцию почти для каждого запроса, а компиляция запроса с длинным списком в предикате IN обходится совсем не дешево. Однако ситуация заметно улучшилась со времен SQL 2000, когда список из 2 000 элементов обрабатывался свыше 10 секунд на всех моих тестовых машинах. В моих тестах на SQL 2005 это случилось только для 10 000 элементов на самой медленной машине. Если Вы повторно используете тот же самый список, есть вероятность нахождения плана в кэше, и в этом случае повторное выполнение будет быстрым. Но имейте в виду, что тогда это должен быть в точности тот же самый список, поскольку кэш чувствителен и к регистру, и к пробелам. Насколько это может быть вероятным? Скорее всего, это создаст нам еще одну проблему, связанную с динамическим SQL: раздувание кэша. Вы будете наполнять процедурный кэш планами, которые очень редко используются повторно. На машинах с большим количеством памяти, это может привести к серьезным проблемам в производительности из-за коллизий хеширования при поиске в кэше. Есть однако способ уменьшить затраты на компиляцию для динамического SQL. SQL 2005 имеет новую опцию базы данных - принудительную параметризацию. Когда эта установка включена, SQL Server параметризует все непосредственно выполняемые операторы. Это проявляется в том, что для динамически построенного выражения IN, аналогичного приведенному выше, для заданного числа элементов списка есть только один вход в кэш, который может повторно использоваться всеми запросами с тем же самым числом элементов. Таким образом, есть один вход для одного элемента, один - для двух элементов и т.д. При таких установках динамический SQL действительно очень быстрый - вплоть до 2100 элементов в списке. 2100 - это максимальное число параметров хранимой процедуры или параметризованного оператора. Когда это число превышено, строка не может быть полностью параметризована, и снова будет один вход в кэш для каждой строки с той же плохой производительностью, как и прежде. И заметьте, что с принудительной параметризацией Вы теряете то, что возможно является самой сильной стороной динамического SQL: оптимизатор имеет полную информацию. При первом вызове, скажем, с пятью элементами списка, Вы можете получить лучший план для этих значений. Но если следующий набор пяти элементов потребует другого плана, то Вы не сможете получить этот план. И поскольку принудительная параметризация - это установка базы данных, Вы не можете полагаться на то, включена она или выключена. (Хотя и есть хинты в запросах для управления их поведением.) Выводом из всего этого является то, что раз Вы получаете хорошие планы при помощи других методов, то нет никакой причины использовать динамический SQL. Только если Вы исчерпали все другие варианты и не смогли получить хорошую производительность, то стоит посмотреть в сторону динамического SQL. И даже тогда Вы должны решить, стоит ли оно того, имея в виду борьбу с разрешениями и принятие мер предосторожности против SQL-инъекции. (Продолжение следует...) Полезная информация§ Приглашаем вас посетить новый проект - Интерактивный учебник по SQL. § Онлайновый выпуск рассылки можно почитать на сайте. § Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § Хотите поддержать проект? Вот инструкция по применению. :-) КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77[@]yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
| В избранное | ||
