(Возврат на основную страницу)
В SQL Server 2005 Beta 2 добавлена поддержка процессора Opteron
Тестовая версия СУБД стала доступной для 500 тысяч разработчиков на сайте MSDN
Джорис Эверс (Joris Evers)
В конце июля компания Microsoft начала развертывать тестовую программу для готовящейся к выпуску СУБД SQL Server 2005 и распространила более подробную информацию о функциях продукта, включая поддержку процессоров Opteron компании Advanced Micro Devices Inc. (AMD).
Представитель компании сообщил, что Microsoft предоставила доступ к версии SQL Server 2005 Beta 2 почти 500 тысячам разработчиков и пользователей через Webсайт Microsoft Developer Network. Он также добавил, что первая бетаверсия была выпущена около года назад, и ее тестировали только 12 тысяч человек.
SQL Server 2005, известный также под кодовым названием Yukon, является преемником SQL Server 2000, выпущенного в конце 2000 года. Улучшения в данном выпуске были направлены на совершенствование управления данными, продуктивность разработчиков и business intelligence, а также они предназначены помочь Microsoft в конкурентной борьбе на рынке СУБД с такими компаниями, как IBM и Oracle.
Начиная со второй бетаверсии, SQL Server 2005 поддерживает процессор Opteron компании AMD, который может выполнять как 32, так и 64битные приложения. Представитель компании сказал, что Microsoft уже поддерживает 64битные процессоры Itanium компании Intel, а также будет поддерживать готовящиеся к выпуску процессоры Xeon с 64битным расширением в будущей версии SQL Server 2005.
Microsoft заявила, что в дополнение к поддержке Opteron в SQL Server 2005 Beta 2 представлен новый инструмент управления, названный SQL Server Management Studio, объединяющий существующие инструменты управления, к которым добавлена поддержка SQL Server Reporting Services, Notification Services, языка Extensible Markup Language и SQL Server 2005 Mobile Edition.
SQL Server 2005 Beta 2 предложит тестировщикам испытать новую функцию шифрования БД, а также тесную интеграцию с инструментом разработки Visual Studio 2005 компании Microsoft и программным обеспечением для глубинного анализа данных (data mining).
Выход третьей бетаверсии SQL Server 2005 ожидается в конце этого года. Ранее Microsoft уже заявила, что откладывает финальную версию редакций 2005 SQL Server и Visual Studio до первой половины 2005 года. Представитель компании сообщил, что этот график выхода попрежнему остается в силе.
Лазейки TSQL
Недокументированные возможности использования хранимых процедур и иных специальных объектов
Ицик БенГан (Itzik BenGan)
Как и любое другое программное обеспечение, SQL Server содержит множество лазеек и иных недокументированных возможностей, используемых программистами. Применение только документированных и поддерживаемых возможностей дает множество преимуществ: ваш код менее подвержен сбоям, вы можете более гладко проводить обновление до свежих выпусков SQL Server, перенос вашего кода на другие платформы более прост и т. д. Однако программисты порою задействуют недокументированные возможности и лазейки, чтобы получить краткосрочные преимущества, такие как быстрое завершение определенной задачи, а также потому, что альтернативные решения не всегда бывают доступными.
Компания Microsoft оставляет недокументированными множество возможностей для того, чтобы разработчики самого SQL Server могли свободно корректировать эти возможности в следующих выпусках или даже в пакетах обновлений. Следовательно, с недокументированными возможностями связан риск, заключающийся в том, что в некоторый момент они могут быть изменены. Кроме того, вы не можете получить поддержку от Microsoft, если эти недокументированные возможности будет работать не так, как вы ожидали от них.
Программисты часто используют лазейки для обхода ограничений продукта, например таких, которые не позволяют использовать ORDER BY в представлениях, но эти ограничения были в основном продиктованы добрыми намерениями, такими как желание соответствия стандартам ANSI. Поэтому, несмотря на краткосрочные выгоды от использования лазеек, вы, скорее всего, поплатитесь за них: при попытке обновления вашего SQL Server использованные вами недокументированные возможности могут больше не работать. Эта статья является первой в серии, раскрывающей некоторые недокументированные возможности и лазейки, используемые программистами на SQL. Несмотря на то, что я не рекомендую использовать их, я надеюсь познакомить вас с ними поближе для того, чтобы вы были лучше подготовлены, если столкнетесь с подобным кодом. Я также должен признать, что эти лазейки очень интересны! Данная статья рассматривает возможности, относящиеся к хранимым процедурам.
Лазейки пользовательских функций
Недокументированные возможности пользовательских функций
Ицик БенГан (Itzik BenGan)
Секреты всегда способны заинтриговать, и лазейки программирования (секретные входы в код приложения) не являются исключением. По ряду причин в предыдущей статье я рассказывал о лазейках TSQL. Вопервых, программисты часто используют недокументированные возможности, о которых вам необходимо знать на тот случай, если потребуется поддержка кода, написанного другими. Вовторых, некоторые недокументированные функции являются полезными, и SQL Server может полностью поддерживать их в течение некоторого времени. И втретьих, конечно, это столь захватывающая тема!
В предыдущей статье серии я начал обсуждение с рассмотрения лазеек, связанных с хранимыми процедурами. На этот раз я продолжу тему, углубившись в лазейки, относящиеся к пользовательским функциям. Я должен еще раз подчеркнуть, что эти недокументированные возможности являются неподдерживаемыми, поэтому я не рекомендую пользоваться ими. Microsoft может изменить их функциональность в будущих выпусках SQL Server или даже в пакетах обновлений. Давайте начнем с первой лазейки пользовательских функций — создания ваших собственных специальных пользовательских функций.
Кто в ответе?
Том Моро (Tom Moreau)
Отношения «многиекомногим» могут оказаться очень коварными при необходимости выполнять внешние соединения. Прочтите статью Тома Моро не только для того, чтобы лучше понять «входы и выходы» LEFT JOIN, но и для того, чтобы понаблюдать за работой профессионала в решении проблем.
Недавно в общедоступной группе новостей мне довелось ответить на крик о помощи. Проблема формулировалась следующим образом: в университете имеются студенты и спортивные игры, студенты могут играть различные роли в каждой из этих спортивных игр. Некоторые из ролей определены как руководящие.
Настройки ограничений с помощью триггеров
Том Моро (Tom Moreau)
Доктор Том Моро обнаружил в Usenet интересную проблему. Возникла необходимость ограничить максимальное количество строк для пунктов одного заказа числом четыре. Как вы могли догадаться, доктор Том воспринял вопрос как вызов: «Думаю, попытка получить ответ на этот вопрос с помощью триггера будет прекрасным упражнением».
Триггеры были частью SQL Server с самого начала (по крайней мере, с тех пор, как корпорация Microsoft унаследовала SQL Server от Ashton-Tate и Sybase; см. в качестве примера на http://support.microsoft.com/search/preview.aspx?scid=kb;en-us;Q45581 старую статью KB о триггерах в версии 4.2). Первоначально триггеры использовались для обеспечения ссылочной целостности (RI), поскольку декларативная ссылочная целостность (DRI) до выхода версии 6.5 еще не была реализована. Но и тогда у нас не появилось то, что большинство считает «полной» DRI. Вплоть до выхода в свет версии SQL2K с ее поддержкой каскадных удалений и обновлений. Но мне кажется, что сегодня триггеры в основном применяются для реализации тех правил ведения бизнеса, которые нельзя воплотить с помощью контрольных ограничений.
Итак, возьмемся за решение одной из проблем бизнеса, которая находится под рукой, — ограничим четырьмя количество строк для записи пунктов одного заказа.
Сбор и хранение данных счетчиков Performance Monitor в таблице SQL Server
Грегори Э. Ларсен (Gregory A. Larsen)
Какие инструменты вы используете, когда контролируете производительность ваших компьютеров SQL Server? Надеюсь, что большинство администраторов БД используют консоль Windows Performance для графического отображения счетчиков производительности для компьютеров SQL Server. Но как можно выявить тенденции производительности для этого компьютера за некоторый период времени? Где вы храните собранные вами данные о производительности при проведении мониторинга компьютеров? Сохраняете ли вы их в таблицах БД на SQL Server?
Эта статья покажет вам, как использовать консоль Performance для настройки журнала счетчиков (counter log) на сбор данных о производительности для SQL Server 2000. Мы обсудим, как загрузить данные производительности в таблицу БД на SQL Server. Я также расскажу о том, как использовать некоторые модули Windows XP для автоматического запуска ваших журналов счетчиков производительности на Windows 2000 Server.
(Возврат на основную страницу)