| ← Июнь 2005 → | ||||||
|
1
|
2
|
3
|
5
|
|||
|---|---|---|---|---|---|---|
|
6
|
7
|
8
|
9
|
10
|
12
|
|
|
13
|
14
|
15
|
16
|
17
|
19
|
|
|
20
|
21
|
22
|
23
|
25
|
26
|
|
|
27
|
28
|
29
|
30
|
|||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru)
| Информационный Канал Subscribe.Ru |
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 41 (25 июня 2005 г.)
 |
Новым посетителям сайтаСайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 59-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. |
Новости сайта
§ Подлатал проверку задачи 67 (замечено молдавским сибиряком).
§ Исправлена ошибка, связанная с регистрозависимостью, которая проявилась при решении задачи 112.
§ Обновил скрипт на базу данных "Корабли". Оно касалось уточнения типов и ограничений NULL|NOT NULL. Данные не изменились. Взять можно здесь.
§ Число подписчиков - 2179Число участников рейтинга - 3393
Число участников второго этапа - 330
Лучшие результаты (ТОР 20)
| No | Person | Number of Sel_ex |
Last_Sel | Number of DML_ex |
Scores | Days | Days_2 | LastSolved | LastVisit |
| 1 | Гонтовой В.А. (noname) | 137 | 137 | 20 | 312 | 68 | 9.705 | 23 May 2005 | 15 Jun 2005 |
| 2 | >Леденев С.А. (Shurgenz) | 137 | 137 | 20 | 312 | 310 | 9.896 | 24 Jun 2005 | 24 Jun 2005 |
| 3 | Галиаскаров Э.Г. (Galogen) | 137 | 137 | 20 | 312 | 185 | 61.297 | 26 May 2005 | 16 Jun 2005 |
| 4 | >Кувалкин К.С. (Cyrilus) | 136 | 41 | 20 | 310 | 212 | 5.020 | 24 Jun 2005 | 24 Jun 2005 |
| 5 | Валуев Д.И. (Fiolent) | 136 | 137 | 20 | 310 | 630 | 26.470 | 26 May 2005 | 24 Jun 2005 |
| 6 | Зверев Д.Л. (dimzv) | 136 | 136 | 20 | 308 | 580 | 2.499 | 06 Jun 2005 | 15 Jun 2005 |
| 7 | Мельникова И.А. (Iris_m) | 135 | 137 | 20 | 308 | 380 | 89.865 | 27 May 2005 | 14 Jun 2005 |
| 8 | Колосов А.С. (KAS) | 134 | 137 | 20 | 306 | 25 | 3.398 | 11 Mar 2005 | 14 Jun 2005 |
| 9 | Сныткин В.Л. (Ded I) | 134 | 136 | 20 | 304 | 252 | 7.456 | 12 May 2005 | 24 Jun 2005 |
| 10 | Рахманов И.Е. (bloom) | 134 | 136 | 20 | 304 | 148 | 14.171 | 11 May 2005 | 15 Jun 2005 |
| 11 | Hakobyan H.H. (hamlet) | 134 | 136 | 20 | 304 | 220 | 37.869 | 07 May 2005 | 03 Jun 2005 |
| 12 | Шипунов И. (IAS) | 134 | 136 | 20 | 304 | 334 | 82.080 | 13 May 2005 | 26 May 2005 |
| 13 | Иткин И.Л. (joseph_itkin) | 132 | 136 | 20 | 299 | 375 | 2.849 | 07 Mar 2005 | 13 Apr 2005 |
| 14 | Spirin (spirin) | 131 | 136 | 19 | 296 | 158 | 13.461 | 21 Jan 2005 | 24 Jan 2005 |
| 15 | Михайлов В.Г. (mslava) | 132 | 136 | 17 | 293 | 648 | 10.504 | 25 Mar 2005 | 25 Mar 2005 |
| 16 | Пятница О.А. (Robin) | 125 | 128 | 20 | 287 | 754 | 74.630 | 19 Mar 2005 | 06 May 2005 |
| 17 | Митронин А.А. (mitronin) | 124 | 124 | 20 | 285 | 701 | 27.585 | 31 May 2005 | 01 Jun 2005 |
| 18 | >Gershovich (VIG) | 123 | 123 | 20 | 282 | 835 | 10.790 | 24 Jun 2005 | 24 Jun 2005 |
| 19 | Булаев В.В. (Kvix) | 119 | 121 | 20 | 274 | 266 | 24.671 | 18 May 2005 | 18 May 2005 |
| 20 | Тортумашев Е.А. (Johnny) | 119 | 121 | 20 | 274 | 219 | 68.741 | 19 May 2005 | 15 Jun 2005 |
Лучшие результаты за неделю
| No | surname | n_sel | sel_all | sel_scores | dml_scores | scores | rating | last_visit |
| 1 | >Силантьев С.В. (silich) | 51 | 51 | 88 | 17 | 105 | 449 | 24 Jun 2005 |
| 2 | >Чехунов П.А. (Евпатий) | 50 | 50 | 85 | 17 | 102 | 477 | 24 Jun 2005 |
| 3 | >Петров А.И. (Lord Alex) | 17 | 60 | 33 | 29 | 62 | 261 | 24 Jun 2005 |
| 4 | >Воронков А. (db) | 29 | 49 | 57 | 3 | 60 | 490 | 24 Jun 2005 |
| 5 | Бойцун Р.В. (BRV) | 30 | 30 | 55 | 1 | 56 | 821 | 24 Jun 2005 |
| 6 | >Стройнов Д.С. (Voland3D) | 17 | 70 | 38 | 9 | 47 | 145 | 24 Jun 2005 |
| 7 | yusupov (yusup) | 23 | 57 | 43 | 3 | 46 | 366 | 24 Jun 2005 |
| 8 | >Ахмадуллин Э.Р. (sCORpio80) | 32 | 32 | 42 | 3 | 45 | 1029 | 24 Jun 2005 |
| 9 | Перонков С.А. (Stas_P) | 24 | 24 | 37 | 7 | 44 | 1121 | 22 Jun 2005 |
| 10 | Dekhtyar (Konstantin) | 26 | 26 | 43 | 0 | 43 | 1014 | 23 Jun 2005 |
| 11 | Малышев Н. (DEDEMAN) | 19 | 26 | 37 | 3 | 40 | 1005 | 23 Jun 2005 |
| 12 | Бураков С.Г. (burakov58) | 20 | 102 | 39 | 0 | 39 | 48 | 24 Jun 2005 |
| 13 | >Дубров А.Е. (Дубров) | 32 | 32 | 39 | 0 | 39 | 1089 | 24 Jun 2005 |
| 14 | Горбачев И.Ю. (jago) | 27 | 27 | 37 | 0 | 37 | 1115 | 18 Jun 2005 |
| 15 | Kusnezow S. (Adept) | 24 | 24 | 37 | 0 | 37 | 1125 | 23 Jun 2005 |
| 16 | >Кузнецов В.А. (str) | 24 | 24 | 37 | 0 | 37 | 1136 | 24 Jun 2005 |
| 17 | Лобода С. (Balu) | 23 | 23 | 34 | 3 | 37 | 1207 | 23 Jun 2005 |
| 18 | >Садовников А.Н. (raul) | 15 | 78 | 36 | 0 | 36 | 112 | 24 Jun 2005 |
| 19 | Balandina (Maggy) | 23 | 27 | 33 | 0 | 33 | 1126 | 19 Jun 2005 |
| 20 | Стельмахов О.В. (DangerTNT) | 22 | 22 | 31 | 0 | 31 | 1313 | 23 Jun 2005 |
| 21 | Рюмина Ю.М. (Белка) | 21 | 21 | 30 | 0 | 30 | 1374 | 23 Jun 2005 |
Изучаем SQL
Как реляционная база данных выполняет и оптимизирует ваш запрос (окончание; начало в вып.40)
Robert L. Bogue (оригинал)
Перевод Моисеенко С.И.
Порядок полей
Порядок полей в индексе весьма важен с точки зрения использования индексов. Решая вопрос об использовании индекса, сервер должен обработать его от первого поля до последнего. Это означает, что оптимизатор запросов может счесть индексы приемлемыми только тогда, когда нужные ему поля располагаются выше (следуют ранее) полей, которые ему не требуются (для выполнения запроса). Если какие-либо незначимые в плане выполнения запроса поля находятся выше нужных оптимизатору запросов полей, то индекс будет проигнорирован за ненадобностью.
Планируя создание индексов, вам следует лишь поместить в вершину индекса те поля, которые часто используются в запросах. Даже одно поле, не являющееся частью необходимых оптимизатору запросов полей, заставит его проигнорировать индекс.
Оценка предложения WHERE
Самая важная часть оператора SELECT для определения того, какой индекс будет использоваться, - предложение WHERE. Предложение WHERE фильтрует записи для вывода и является первым кандидатом для оптимизатора запросов при выборе индекса. Имеется несколько различных способов использования предложения WHERE. Наиболее общие формы подробно объясняются ниже:
Соответствие (равенство)
Самый общий пример того, как используется предложение WHERE, состоит в соответствии записи или набора записей. Когда вы указываете, что определенное поле равно некоторому значению, оптимизатор запросов знает, что он может пойти на поиск единственной записи в индексе или небольшого диапазона записей, чтобы идентифицировать записи в базовой таблице, которые удовлетворяют запросу. Это позволяет значительно уменьшить необходимое число чтений из физической таблицы, чтобы сократить время выполнения запроса. Анализатор запросов будет искать индексы, которые содержат поля, упомянутые в операторе равенства.Больше или меньше чем
Хотя соответствие и равенство, безусловно, являются наиболее используемыми, в предложении WHERE нередко запрашиваются диапазоны. В этом случае анализатор запросов знает, что он может выполнять поиск в той части индекса, которая больше или меньше указанного значения. Обычно анализатор запросов может определить с помощью многократных индивидуальных операторов, какую процентную долю индекса он должен прочитать, и на основании этого может решить, имеет смысл использовать индекс или нет.Функции
Использование функций в предложении WHERE может ограничить способность анализатора запросов определять насколько полезным может оказаться тот или иной индекс. Поскольку анализатору запросов не очевиден результат функции, особенно в случае, когда функция применяется к полям, а не константам, использование функций в предложении WHERE уменьшит шансы того, что анализатор запросов сможет оценить полезность некоторого индекса, независимо от того, какие поля при этом рассматриваются.Оценка предложения ORDER BY
Как только анализатор запросов обработает предложение WHERE, он обратится к предложению ORDER BY. То, что ищет оптимизатор запросов, - это способ, который не приведет к необходимости пересортировки уже полученных результатов. Если оптимизатор запросов сможет найти индекс, который уже содержит строки, расположенные в правильном порядке, и они соответствуют предложению WHERE, он будет использовать этот индекс так, чтобы избежать результирующей сортировки.
Чтобы стимулировать использование индексов, ваше предложение ORDER BY не должно содержать ненужных (лишних) полей. Поскольку анализатор запросов не знает, какое поле в предложении ORDER BY имеет для вас значение, а какое - нет, он исходит из того, что все они нужны. В результате, если вы включаете поля в предложение ORDER BY, оптимизатор должен попытаться найти индекс, который содержит все перечисленные поля. Перечисление всех полей в предложении ORDER BY будет, по существу, препятствовать оптимизатору запросов в использовании индекса.
Покрытие индексами
Выше я упоминал, что анализатор запросов предполагает наличие штрафа, который нужно заплатить за обращение к индексу, и из-за этого он будет иногда избегать использовать индексы, которые упорядочены по правильным полям. Это справедливо за исключением специального случая, когда индекс содержит все необходимые поля запроса.
Если, например, вы выбираете только User ID, First Name, LastName и EmailAddress из записи пользователя, и у вас имеется индекс, который содержит все эти поля, то анализатор запросов сможет использовать индекс и вообще не обращаться к базовой таблице с требуемыми данными.
Это может быть особенно полезным в случае, когда вы имеете таблицу перекрестных ссылок, которая используется в обоих направлениях. Вы создаете кластеризованный индекс в одном направлении, а затем создаете индекс с полями в обратном направлении. Результат состоит в том, что сервер SQL может использовать физическую таблицу, когда движется в первом направлении и ограничиться исключительно использованием индекса в обратном направлении.
Покрытие индексами требует дополнительного пространства в базе данных и требует большего времени на обновление из-за более длинных ключевых значений; однако это наилучший способ помочь анализатору запросов, если Вы имеете относительно статичную перекрестную таблицу ссылок, которая используется очень часто.
Помоги оптимизатору запросов
Есть набор действий, который анализатор выполняет всякий раз, когда вы отправляете запрос. Эти действия направлены на то, чтобы помочь вам получить результаты наиболее быстро; однако, это работает только тогда, когда вы сами можете помочь оптимизатору запросов делать его работу, задавая только то, что вам необходимо получить и создавая правильные индексы.
Полезная информация
Конкурс
§ Мы выставили наш сайт на конкурс Интернить 2005. Победитель определяется числом поданых голосов. Просьба проголосовать. (рекомендуемая оценка 3 :-)).
Контакты
По всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте.
| Subscribe.Ru
Поддержка подписчиков Другие рассылки этой тематики Другие рассылки этого автора |
Подписан адрес:
Код этой рассылки: comp.soft.db.sqlex |
Отписаться
Вспомнить пароль |
| В избранное | ||
