(Возврат на основную страницу)
Наверное, нет разработчика, который не слышал о следующей версии SQL Server с кодовым названием «Yukon».
Хотя технически SQL Server 2000 входит в группу продуктов Enterprise Server из Microsoft .NET и является, таким образом, продуктом .NET, в нем нет многих основных функций .NET. В силу этих причин именно Yukon часто рассматривается как первый SQL Server, по-настоящему интегрированный с .NET. В связи с этим многие читатели интересуются: чего ожидать от новой версии? Недавно я сделал подборку вопросов пользователей и попросил ответить на них Стива Мурчи (Steve Murchie), менеджера группы создателей продукта Microsoft SQL Server. Вот что он сказал.
Нужно ли дожидаться выхода Yukon, чтобы получить настоящий .NET SQL Server, или будет создан сервисный пакет для расширения функциональности .NET в существующих версиях?
Вся технология Microsoft .NET ориентирована на создание приложений, поддерживающих Web-сервисы на основе XML. С этой точки зрения, SQL Server — замечательная платформа, обладающая мощной поддержкой XML и стандартов Интернета. По мере развития SQL Server мы будем расширять его возможности, что позволит повысить производительность разработчика, создающего Web-сервисы на основе XML. И все же в настоящее время наши клиенты успешно создают и развертывают Web-сервисы на платформе SQL Server 2000.
Какие изменения и новые возможности ожидаются в Yukon? Можно предположить, что одним из них будет улучшенная поддержка XML, а что еще?
SQL Server 2000 уже предлагает лидирующую в отрасли поддержку XML, и мы регулярно обновляем эти возможности с помощью улучшений, распространяемых через Web. Они доступны по адресу: http://msdn.microsoft.com/sqlserver. От Yukon можно ожидать улучшения общей программируемости, дополнительных инноваций в масштабируемости и доступности, а также расширение функциональности хранилищ данных и интеллектуальной поддержки бизнес-задач (business intelligence). Несомненно, особое внимание будет уделено расширению и углублению поддержки XML для OLTP и организации хранилищ данных.
Пострадает ли производительность сложных хранимых процедур из-за замены кода T-SQL эквивалентным кодом CLR?
Мы не ожидаем снижения производительности из-за использования кода CLR, поскольку он дает преимущества при компиляции. Мы продолжим работу над оптимизацией производительности T-SQL. Думаю, с выходом VS.NET картина станет яснее.
Будет ли в SQL Server поддержка типа данных array, или необходимость в ней отпадет после интеграции CLR и Yukon?
SQL Server 2000 поддерживает весьма полезный тип данных table. Однако с выходом Yukon появится выбор между использованием типа данных array любого из языков, поддерживаемых CLR, и традиционных типов данных, поддерживаемых механизмом SQL Server.
По мере роста доли SQL Server на рынке и всеобщей заинтересованности в .NET мы будем с нетерпением ожидать появления дальнейших сведений о Yukon в ближайшем будущем. SQL Pro надеется вскоре представить вам более полный обзор.
Дэвид Рэбб (David Rabb)
Генерируйте стандартизированные хранимые процедуры с помощью объектов DMO SQL Server
Во избежание неприятностей не давайте пользователям прямого доступа к таблицам БД. В Microsoft SQL Server имеется один из лучших методов изоляции пользователей от таблиц — хранимые процедуры. И все же, если у вас нет утилиты проектирования БД промежуточного уровня, вам, вероятно, приходится создавать и поддерживать хранимые процедуры вручную. Ниже я расскажу, как с помощью метаданных SQL Server создать и поддерживать набор стандартизированных хранимых процедур для любой БД SQL Server (рис. 1).
Я покажу, как создать процедуры, выполняющие выборку, вставку, удаление и модификацию данных для любой пользовательской таблицы БД Pubs (см. исходный код в прилагаемом архиве). Процедура выборки, принимая по одному параметру для каждого элемента первичного ключа таблицы и собственно оператор SELECT, возвращает все поля отдельной записи таблицы.
Процедура Insert вставляет в таблицу одну запись и принимает параметры для каждого поля этой записи. Мой проект заменяет все значения NULL, переданные процедуре Insert, значениями по умолчанию (если таковые определены). Insert возвращает значения по умолчанию в форме параметров вывода. Все параметры для полей типа IDENTITY также нужно определить как параметры вывода и вернуть значение IDENTITY, вставленное в новую запись.
Update обновляет отдельную запись, основываясь на первичном ключе таблицы. Уникальность данной про- цедуры в том, что вам надо передать параметры как для исходных, так и для текущих значений полей первичного ключа. Раздел WHERE команды Update ссылается на исходные, а оператор SET — на текущие значения. Процедура Delete удаляет отдельную запись, основываясь на первичном ключе.
Энди Уоррен (Andy Warren)
В этой статье я продемонстрирую несколько примеров использования DMO, которые послужат вам отправной точкой для разработки собственных решений. Все примеры написаны на VB Script, но вы можете использовать любой другой язык программирования, поддерживающий COM. Исходный код тестировался на SQL Sever 2000, но должен работать и на SQL Sever 7.0.
Объектная модель SQL-DMO предоставляет программный (COM) интерфейс для работы с SQL Server. Это великолепный инструмент автоматизации рутинных задач, во многих случаях намного более гибкий, чем T-SQL.
Свои сценарии SQL-DMO я создаю на Visual Basic и затем преобразовываю их в VBScript. Если вы поступаете так же, не забудьте о следующих правилах.
Рон Тэлмейдж (Ron Talmage), ITworld.com
Высокопроизводительные решения для хранения данных SQL Server больше не ограничены использованием обычных копий.
Информационные технологии постоянно сталкиваются с двумя конфликтующими потребностями. С одной стороны, приходится хранить все больше и больше данных, с другой - пользователям нужен доступ к онлайновой информации днем и ночью, поэтому ожидается увеличение периодов доступности БД.
Проблема в том, что на резервное копирование БД, когда она разрастается до 50–100 Мб (а в наши дни это не редкость), уходит масса времени. До сих пор такие БД приходилось отключать от сети на время восстановления.
Но помощь уже не за горами: например, производители устройств для хранения данных пытаются обеспечить непрерывную доступность БД с помощью исключительно быстрых систем, использующих разделение зеркалированных массивов (split mirror), хранящих копии моментальных снимков (snapshot backup). В то же время разработчики ПО для резервного копирования на ленту предлагают копирование при записи (copy-on-write). Оно работает не так быстро, как аппаратные системы, но все же быстрее обычных методов резервного копирования. Новая функция копирования моментальных снимков позволяет реализовать в SQL Server 2000 оба типа резервного копирования.
Митчел Харпер (Mitchell Harper)
Здесь рассказывается о создании объектов (типа БД, таблиц и хранимых процедур) в SQL Server «на лету». В статье приведен пример идеальной программы, позволяющей распространять созданные объекты на нужное количество серверов и отражать обновления одновременно на нескольких серверах. Возможно, это окажется непрактичным, но даст хорошее представление о разработке приложений с применением Windows DNA: любую задачу всегда можно решить несколькими способами. Митчел Харпер приводит альтернативный метод решения описанной выше задачи.
Один из самых важных методов разработки приложения - создавать функциональный код с возможностями многократного использования. Рассмотрим, например, ситуацию, в которой нам нужно создать функцию для приложения на тестовом компьютере и затем воспроизвести этот код на рабочих компьютерах. «Это просто», - скажете вы. Да. Если код приложения включает COM-объекты и ASP-сценарии.
А если у вас свое небольшое дело и вам требуется быстро и просто создать БД для проекта, но вы не знаете, как сделать это с помощью SQL-сценариев?
Одно из простых решений — написать программу, способную «на лету» создавать такие объекты (БД, таблицы и хранимые процедуры) в SQL Server. Идеальное приложение позволило бы разработчику распространить эти объекты на нужные серверы и отразить обновления сразу на нескольких серверах. Возможно, в реальном мире такой метод создания БД окажется непрактичным, но он дает хорошее представление о разработке приложений с помощью Windows DNA: любую задачу всегда можно решить несколькими способами. Мы обсудим альтернативный метод решения описанной выше задачи.
Кирк Ален Эванс (Kirk Allen Evans)
Одно из ключевых достоинств объектов ActiveX Data Objects (ADO) - их способность выполнять запросы, адресованные к разнородным источникам. Однако иногда, чтобы получить дополнительные возможности по построению запросов или для освежения данных нужно перебросить данные из одного источника в другой. ADO и XML позволяют взять данные из одного источника и направить их во вновь создаваемый. Комбинация ADO и XML позволяет напрямую работать с наборами данных, минуя ADO API, расширив таким образом функциональные возможности объекта Recordset.
Упражнения с базой данных Northwind из SQL Server помогут вам узнать, как ADO обрабатывает XML, созданный методом Save из набора записей (recordset) ADO. Этот метод позволяет решить несколько проблем, связанных с передачей данных. Например, вы не видите в целевой таблице вновь созданные строки, если читаете информацию из источника данных, отсоединяете объект Recordset, устанавливаете ему в свойстве ActiveConnection другой источник или выполняете оператор UpdateBatch. Это связано с тем, что при чтении данных из БД посредством оператора SELECT ADO получает копию данных, не производя с ними никаких действий. А так как с данными вы ничего не делали, вызов UpdateBatch по отношению к набору записей не возымеет эффекта. То же происходит, когда вы привязываете объект Recordset к другой БД: хотя это может быть другая БД и даже не иметь данных, вы по-прежнему не дали указаний ADO что-то с этими данными делать, и поэтому опять ничего не происходит. Отчасти это связано с тем, что команды UPDATE и INSERT не связаны с этим оператором, а также с тем, что Recordset все еще нацелен на прежнюю БД.
Джон Раушенбергер (Jon Rauschenberger)
Сделайте свои данные по-настоящему масштабируемыми с помощью распределенных секционированных представлений в SQL Server 2000.
Создать по-настоящему масштабируемое приложение, которое будет таковым «от начала до конца», можно лишь путем распределения данных по нескольким серверам. Секционирование данных (data partitioning) - мощный инструмент, проверенный во многих крупных системах. Кроме того, теперь реализовать эту методику стало легче, чем когда-либо, поскольку в таких программах, как SQL Server 2000, теперь имеется встроенная поддержка секционирования данных.
Под секционированием данных понимают определение правила (или набора правил), позволяющее вычислить, на каком из серверов должны размещаться данные. Далее нужно реализовать механизм, который применяет это правило, представляющий данные в виде непрерывного набора. Это позволит увеличивать емкость БД, просто добавляя новые серверы и модифицируя правила секционирования (partitioning rules).
Мотивы использования секционирования данных таковы. Даже если ваши Web-серверы могут обрабатывать неограниченное количество пользователей, потенциальным «узким местом» является база данных. Именно она ограничивает число пользователей, которое в состоянии поддерживать ваша система. Можно увеличивать число Web-серверов и серверов приложений в «серверных фермах» (server farms), но если БД может обработать лишь ограниченное число транзакций, выбор невелик: зачастую единственным способом решения проблемы является покупка более мощного сервера БД. В идеале следует применять аналогичный подход (масштабирование путем наращивания) для масштабирования БД, которая является основой масштабирования остальных компонентов приложения. Горизонтальное масштабирование (Scaling out) — это увеличение пропускной способности системы путем увеличения числа машин в платформе, на которой работает ваша система. Если Web-приложение, работающее на «ферме» Web-серверов, начинает тормозить из-за недостаточной пропускной способности, можно без труда расширить машинный парк фермы.
Однако применить эту методику к БД, данные которой доступны для чтения и записи, - задача нетривиальная. Реляционные БД выполняют огромную работу по управлению операциями обновления, добавления и удаления, выполняемых над хранилищем данных. Им известно, как блокировать, изменять данные и проверять их целостность. Но чтобы выполнять эту работу, серверу БД нужен полный контроль над изменяемыми и всеми связанными данными. Если нужно распределить данные по нескольким серверам, это становится проблемой. Но она решается с помощью секционирования данных.
(Возврат на основную страницу)