Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru) 181
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)" Выпуск 181 (15 марта 2008 г.)Новым посетителям сайта Сайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения
состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.
Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 57-ти задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов, которые пригодятся на третьем рейтинговом этапе, который начинается после 138 задачи.Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. Новости сайта§ Одна задача до третьего этапа осталась xuser и все шансы на первое место по итогам второго этапа (задач 137, время 2.132). § Изменения среди лидеров (решенные за неделю задачи третьего этапа): § Новые лица в ТОР 100 и вернувшиеся туда: § Продвинулись в рейтинге: § Продвижение ближайших претендентов на попадание в ТОР 100: § На этой неделе сертифицированы: § Число подписчиков - 3739 Число участников рейтинга - 14765 Число участников второго этапа - 1286 Число участников третьего этапа - 27 Сертифицировано на сайте - 247 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQL5 вещей, которые каждый разработчик SQL должен знать, как свои пять пальцев...James Luetkehoelter (оригинал: 5 things every SQL developer should know like the back of their hand... )Перевод Моисеенко С.И. После того, как я написал о 5 вещах, которые должен знать каждый администратор баз данных, я подумал, что следует продолжить публикацией моих представлений о том, что должен знать любой разработчик... 1) Всегда уточняйте имена объектов. Никакие слова не будут достаточны, чтобы сказать о важности этого пункта. Даже если Вы не имеете никаких схем (схем SQL 2005, я имею в виду), всегда ссылайтесь на объекты при помощи, по крайней мере, DBO.[имя_объекта]. Если вы последовательны в вызовах таблиц, представлений, хранимых процедур, функций и т.д., то ощутите прирост производительности. Проблема в том, что если Вы просто пишете ваш код так...
SELECT LNAME, FNAME FROM PERSON
... Вы потенциально создаете 2 операции на сервере. Первая будет проверять ваш конкретный контекст безопасности, чтобы увидеть, являетесь ли вы владельцем объекта, а затем будет использоваться псевдоним DBO (между прочим, если Вы заходите с привилегиями sysadmin или db_owner, DBO приписывается автоматически, - но это не оправдание тому, чтобы приложение подключалось с правами sysadmin или db_owner). Скажем, я авторизовался как пользователь SQL 'James'. В предыдущем примере, процессор запросов сначала должен проверить, существует ли 'James.PERSON'; в противном случае, будет использоваться DBO.PERSON. Зачем тратить на это время. Я пошел бы еще дальше, и уточнил также имена столбцов:
SELECT PERSON.LNAME, PERSON.FNAME FROM DBO.PERSON
Конечно, замечательно, если вы используете псевдоним таблицы в запросе ('p. LNAME'). Это еще более полезно в виду возможной неоднозначности при выполнении соединений, однако есть некоторая выгода и с точки зрения производительности (скорее, измеряемой, чем ощущаемой). 2) Понимать логику, основанную на теории множеств. Многие тут же скажут: "Избегайте курсоров TSQL как чумы", но меня больше волнует соотношение между теоретико-множественной и итеративной логикой. SQL (во всех его многих проявлениях - это ведь проблема не только SQL Server) - это язык, опирающийся на теорию множеств. Он разработан или оптимизирован не для построчной обработки списка записей (прежде, чем Вы скажете это, да, даже форма курсора представлена множеством, что теперь официально называется результирующим набором - resultset - по умолчанию; хотя некоторые из нас еще помнят его как курсор пожарного шланга - firehose). Иногда итеративный проход по списку записей является неизбежным. Иногда Вам требуется это сделать в TSQL - именно поэтому там имеются курсоры. Однако если Вам требуются итерации, передача набора в другой язык (ADO.NET, например) для обработки может быть более эффективным решением. Но то, что я вижу чаще всего, - это просто недостаток понимания теоретико-множественных операций; многие разработчики предпочитают думать итеративно. Работая с базами данных SQL, приобретение практического знания логики на основе множеств может стать огромным шагом к уходу от курсоров TSQL. 3) Доступ к объектам в согласованном порядке. В частности, в SQL Server по умолчанию используются пессимистические блокировки (только SQL 2005 предлагает оптимистические, и это стоит того). В чем же состоит проблема на практике? Если кто-то читает данные, то никто не может перезаписывать эти же данные. Учитывая используемый механизм блокировок, это может привести к блокированию большого объема данных, что представляет собой самую большую "скрытую" проблему потери производительности в SQL Server. Что еще хуже, - это возможность тупиков - SQL просто выбирает жертву, действие которой отменяется (не спрашивайте меня о точном алгоритме, могу лишь сказать, что это сложней, чем реализация очереди - FIFO). Чтобы избежать тупиков и минимизировать объемы блокирования, всегда организуйте доступ к объектам в одном и том же порядке. Например, вместо Сессия 1: UPDATE PERSON... UPDATE ADDRESS... SELECT PERSON... SELECT ADDRESS... Сессия 2: UPDATE ADDRESS... UPDATE PERSON... SELECT ADDRESS... SELECT PERSON... Который, вероятно, приведет к взаимной блокировке сессий 1 и 2, все сессии, выполняющие подобные действия должны выполняться в одном и том же порядке. При таком способе блокировки для других сессий, как правило, будут сниматься более быстро, и вероятность тупиков будет значительно ниже. Минимизируя блокировки, Вы сможете серьезно улучшить производительность вашего кода SQL. Это верно вообще, но особенно верно в SQL Server из-за пессимистических блокировок. 4) Использование согласованных поисковых аргументов. Поисковые аргументы (известные фанатам баз данных как SARGs - не вполне акроним), могут сделать ненужным оптимизатор запросов. Если Вы не отдаете себе отчет в том, как организуется доступ к объектам в вашем предложении WHERE, оптимизатор запросов может дать несколько странноватые результаты. Например, если Вы имеете составной индекс на LNAME, FNAME, но используете 'WHERE FNAME ='James' AND LNAME ='Luetkehoelter'", есть некая вероятность, что индекс использоваться не будет. Имеется множество факторов, которые требуется учитывать, но если все факторы на месте, то простое упорядочивание становится той пушинкой, которая нарушает равновесие. Что еще хуже, так это то, что администратору базы данных становится более трудным настроить индексы, когда код ведет себя непредсказуемо. Воздействие на внутренние планы выполнения запроса, как то статистика по столбцам и индексы, а также возможность автопараметризации для запросов, передаваемых непосредственно, станет почти невозможным. Просто решите для себя, каким должен быть порядок для любого предложения WHERE и следуйте ему. Даже если этот порядок не будет "оптимальным", согласованность позволит избежать некоторого количества весьма уродливых ситуаций настройки. 5) Избегать искушения XML. Ну, хорошо, SQL Server 2005 имеет встроенный тип данных XML и индексы XML, и поддержку XQuery 1.0. Это все означает, что данные могут сохраняться в виде XML, а поиск и извлечение отдельных документов даже усиливается индексами. Я действительно думаю, что они это - огромные возможности, однако... Доступ к XML-файлу более медленный по сравнению со стандартным доступом к реляционным данным. Являясь привлекательным с точки зрения разработки для хранения данных (и я думаю, что это и есть предназначение XML), XML ПО СВОЕЙ СТРУКТУРЕ НЕ ПРЕДНАЗНАЧЕН ДЛЯ ПОСТОЯННОГО ХРАНЕНИЯ И ПОИСКА. Некоторые могут увидеть здесь противоречие, но для меня это - факт. Я использовал тип данных XML для "обезвоживания" экземпляра объекта, или для хранения исторических или оригинальных документов XML. Я никогда не стал бы защищать применение типа данных XML для непрерывного чтения, записи и обновления. Даже со всеми своими улучшениями в 2005 (и в грядущем 2008), это все еще тип данных, которому нужен "рожок для обуви", чтобы впихнуть его в реляционную структуру хранения. Если Вы должны использовать XML, попробуйте минимизировать непрерывную работу с такими данными внутри сервера SQL. 17-09-2007 Полезная информация§ Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § Желающих поспособствовать популяризации сайта прошу проголосовать/поставить закладку в социальных сетях: КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
| В избранное | ||
