| ← Декабрь 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) 219
Новости сайта "Упражнения по SQL (http://www.sql-ex.ru)"Выпуск 219 от 06 декабря 2008 г.Новым посетителям сайта Сайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения
состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.
Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается сейчас после решения 50-й задачи первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Демонстрация плана выполнения запроса и сравнительная оценка эффективности решений поможет вам освоить принципы оптимизации запросов, которые пригодятся на третьем рейтинговом этапе, который начинается после 138 задачи.Имеется возможность получить сертификат по SQL DML при выполнении определенного количества заданий. Новости сайта§ Добавил проверочных данных (сообщения от noname) для задач 18 (DML) и 56 (SELECT). § Изменения среди лидеров (решенные за неделю задачи третьего этапа): § Новые лица в ТОР 100 и вернувшиеся туда: § Продвинулись в рейтинге: § Продвижение ближайших претендентов на попадание в ТОР 100: § На этой неделе сертифицированы: § Число подписчиков - 3821 Число участников рейтинга - 19870 Число участников второго этапа - 1621 Число участников третьего этапа - 44 Сертифицировано на сайте - 343 Лучшие результаты (ТОР 20)
Лучшие результаты за неделю
Изучаем SQLМассивы и списки в SQL Server 2005 (начало в вып.217, 218)Erland Sommarskog (оригинал: Arrays and Lists in SQL Server 2005 )Перевод: Моисеенко С.И. Общие вопросыИнтерфейсБольшинство методов, которые я представлю тут, упаковано в функции, которые принимают входной параметр, являющийся списком значений, а возвращают таблицу, например: CREATE FUNCTION list_to_table (@list nvarchar(MAX)) RETURNS @tbl TABLE (number int NOT NULL) AS Причина, по которой методы находятся в функциях, очевидна: это позволяет вам повторно использовать функцию во множестве запросов. Здесь я хочу обсудить некоторые вопросы, связанные с интерфейсом таких функций. Входные параметрыВ этой статье входной параметр всегда имеет тип данных nvarchar(MAX). Это новый тип данных в SQL 2005, который может содержать до 2 Гб данных, как старый тип данных ntext, но при этом nvarchar (MAX) не имеет многих причуд типа ntext. Я остановился на этом типе, поскольку хочу сделать функции настолько общими, насколько это возможно. При использовании nvarchar функции могут обрабатывать входные данные в кодировке Unicode, при этом MAX не накладывает ограничения на размеры входных параметров. При использовании nvarchar (4000) они начинали бы давать неправильные результаты на больших размерах входных данных. Однако за такой выбор приходится платить производительностью. Если Вы используете коллацию SQL, то должны знать, что varchar дает лучшую производительность. А некоторые операции выполняются медленнее с типами данных MAX. Таким образом, если Вы знаете, что ваши списки никогда не будут превышать 8000 байтов, и Вы будете работать только с вашей кодовой страницей ANSI, и Вам требуется максимально возможная производительность, не стесняйтесь использовать varchar (8000) вместо этого типа. Некоторые из функций имеют второй параметр, позволяющий Вам задать разделитель или, в случае фиксированной длины, длину элемента данных. В некоторых функциях я задаю разделитель в коде, но для всех методов, которые требуют разделителя (кроме динамического SQL), Вы можете всегда добавить такой параметр. Для простоты я везде использовал односимвольные разделители. Если Вам требуются в мультисимвольные разделители, большинство методов легко может быть обобщено и на этот случай. Выходная таблицаФункции возвращают таблицу. Для всех методов, я включил одну функцию, возвращающую таблицу строк, а для некоторых методов еще и функцию, возвращающую таблицу целых чисел. (Что, вероятно, будет наиболее общим типом данных для такого типа списков.) Если Вы имеете список целых чисел и функцию, которая возвращает строки, Вы можете поступить следующим образом: SELECT ... FROM tbl t JOIN list_to_table(@list) l ON t.id = convert(int, t.str) Аналогично можно поступить с другими типами данных. Вы можете легко клонировать версию функции, которая содержить встроенное преобразование. (Однако загляните в раздел Надежность для уверенности.) Тип данных, который требует большего внимания - строки. Что возвращать nvarchar или varchar? Очевидно, когда Вы работаете с данными Unicode, следует возвращать строки типа nvarchar. Это может заставить всегда возвращать nvarchar, но по причинам, которые я рассмотрю в разделе производительности, следует удостовериться в том, что получаете строку varchar, когда выполняется соединение со столбцом varchar. Для некоторых методов возвращаемая таблица содержит сразу два столбца с типами varchar и nvarchar соответственно. В некоторых функциях, я также возвращаю позицию в списке для элементов списка. Это может оказаться удобным, когда Вы имеете два или более списков, которые являются горизонтальным разбиением того же самого источника. В результате можно поступить, например, так: INSERT tbl(id, col2, col3) SELECT a.number, b.str, c.str FROM intlist_to_table(@list1) a JOIN charlist_to_table(@list2) b ON a.listpos = b.listpos JOIN charlist_to_table(@list3) c ON a.listpos = c.listpos Таким образом, это способ вставить много строк за одну операцию и способ действительно лучший. Все будет в порядке, если у Вас только два или три столбца на вставляемую строку, но по мере роста числа параллельных списков контроль становится сложнее, и вместо этого Вы должны рассмотреть возможность использования XML. Специфическая опасность данного подхода состоит в том, что, если списки не синхронизированы друг с другом, Вы вставите неправильные данные. Для некоторых методов позиция в списке может легко быть выведена непосредственно из метода, для других (но не всех) Вы можете использовать функцию row_number (), очень ценное дополнение к SQL 2005. НадежностьНельзя отрицать, что парсинг строк несколько рискован. Пока входные параметры подчиняются правилам, все идет прекрасное, но что происходит, если это не так? Хорошая функция список-в-таблицу сможет защитить Вас от некоторых несчастных случаев, но не от всех. Ниже несколько ситуаций, которые нельзя упускать из виду. Разделитель на входеСкажем, что у нас есть несколько названий городов, например: Berlin, Barcelona, Frankfurt (Main), Birmingham, K?benhavn. Из них Вы хотите составить разделенный запятыми список, который Вы передаете в функцию список-в-таблицу. С приведенными выше названиями, все работает прекрасно, но затем некий шутник вводит Dallas, TX. Oh-oh. Есть несколько способов избежать этой проблемы. Так, можно использовать разделитель, который вряд ли появится во входных данных, например, управляющий символ. Многие программы заключают строки в кавычки, т.е. список выглядел бы так: "Berlin","Barcelona" и т.д. Этот последний формат не поддерживается ни одной из моих функций, но Вы можете немного доработать некоторые из них для учета и такого варианта. Иногда вообще нельзя сделать никакого предположения о разделителе, например, если входной параметр формируется вводом пользователя или передается по сети. В таком случае придется использовать методы с общим механизмом вывода, один из которых, остроумно использующий XML, я вам и представлю. Или можно совсем избежать проблем с разделителями, используя строки фиксированной длины. Когда Вы работаете со списками целых чисел, это, весьма вероятно, не будет вызывать проблем. Дополнительный пробелыЕсли Вы имеете такой список на входе: ALFKI, VINET, BERGS,FRANK Хотите ли вы, чтобы дополнительные пробелы были включены в данные, возвращаемые функцией list-to-table? Вероятно, нет. Все функции в этой статье удаляют начальные и конечные пробелы в элементах списка. Однако есть некоторые методы, где это не возможно. (Или, более точно, они не в состоянии обработать несогласованные пробелы.) Недопустимый вводСкажем, у нас есть функция, которая принимает список целых чисел. Что произойдет, если на входе будет такой список: 9, 12, a, 23, 12? Без специального кодирования SQL Server сообщит вам об ошибке преобразования, и выполнение пакета будет прервано. Если Вы предпочитаете, можно добавить проверки в вашу функцию, чтобы недопустимые значения игнорировались или заменялись на NULL. Чтобы не отвлекаться на посторонние детали, я не добавлял такие проверки в функции для этой статьи. Пустые элементыЧто, если на вход вашей функции, которая принимает список целых чисел, поступит: 9, 12,, 23, 12. Как следует интерпретировать двойную запятую? Если Вы выполните простое преобразование, то получите 0, что не очень хорошо. Было бы лучше вернуть NULL или просто не учитывать этот элемент. (Сгенерировать ошибку? Вы не можете генерировать ошибки в функциях.) В некоторых функциях этой статьи я применяю один прием, позволяющий избежать всех этих проблем посредством использования пробела в качестве разделителя. Но так как T-SQL не предоставляет функции для обработки внутренних пробелов, данный подход не лишен проблем. Для методов, которые основываются на логике традиционного программирования, Вы можете легко обработать множественные пробелы, но для методов, который используют комбинацию charindex и теоретико-множественный подхода, Вы вынуждены отфильтровывать пустые элементы в предложении WHERE. (Чего я не делаю в этой статье.) (Продолжение следует...) Полезная информация§ Приглашаем вас посетить новый проект - Интерактивный учебник по SQL. § Онлайновый выпуск рассылки можно почитать на сайте. § Все статьи, публикуемые в рассылке, затем выкладываются на сайте Книги и статьи по SQL. § Хотите поддержать проект? Вот инструкция по применению. :-) КонтактыПо всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77[@]yandex.ru. Вы также можете предложить свои задачи для публикации на сайте. |
| В избранное | ||
