(Возврат на основную страницу)
Microsoft готовит встроенную базу данных
Первым шагом в реализации плана Microsoft по модернизации флагманской СУБД SQL Server станет выпуск с периодичностью дватри года встроенной базы данных для портативных устройств.
Пол Флешнер, старший вицепрезидент компании по серверным приложениям, обрисовал задачи софтверного гиганта в области разработки следующих двух версий SQL Server. Он добавил, что продажи выпущенного недавно SQL Server 2005 потрясли руководство компании и внесли вклад в 20%й рост доходов за последние два финансовых квартала.
Флешнер рассказал, что этим летом выйдет ранняя версия (community technology preview) новой СУБД SQL Server Everywhere Edition. Она должна быть готова во втором полугодии. SQL Server Everywhere — это «встроенная» база данных, предназначенная для хранения информации в таких портативных устройствах, как мобильные телефоны (чтобы для доступа к данным не надо было устанавливать контакт с сервером). Microsoft уже разработала ее для внутреннего применения, а теперь выпустит ее на внешний рынок.
Другие компании, такие как Oracle, IBM и Sybase, уже предлагают подобные продукты. Кроме того, существует несколько вариантов open source, таких как технология Sleepycat, недавно приобретенная Oracle.
По поводу будущих продуктов Флешнер сказал, что Microsoft выявила несколько тенденций в сфере хранения данных, которыми будут обусловлены планируемые функции следующих двух версий SQL Server. В частности, прогнозы указывают на продолжение быстрого роста объемов данных, существенное снижение стоимости их хранения, так что на один диск за $100 будет помещаться 1 Тб данных, а также предполагается появление мощных устройств, таких как телефоны, фотокамеры и цифровые музыкальные плееры, способные хранить все больше и больше данных.
Учитывая эти изменения, Microsoft разрабатывает методы более рационального хранения файлов изображений, музыкальных записей и других «неструктурированных данных». Также инженеры трудятся над совершенствованием инструментов для анализа данных и администрирования БД. Чтобы облегчить обмен информацией между клиентскими устройствами и серверами, создаются инструменты для разработчиков, упрощающие синхронизацию данных между машинами.
«Мы не столь наивны, чтобы верить, что все данные будут храниться в одной центральной БД, — заявил Флешнер. — Люди не станут понапрасну носить с собой в кармане терабайт данных».
Метаданные внешних ключей: совершенствование с помощью представлений INFORMATION_SCHEMA
Независимо от того, применяете ли вы представления INFORMATION_SCHEMA (функциональные возможности метаданных, совместимых с ANSI, впервые были введены в SQL 7.0), думаю, вас заинтересует подход Рона Тэлмейджа, позволяющий приобрести дополнительные знания в этой области.
Иногда необходимо выполнять задачи в базе данных SQL Server 2000, которые требуют доступа к метаданным БД. Для получения метаданных можно воспользоваться системными таблицами, однако Miscrosoft рекомендует применять представления INFORMATION_SCHEMA и функции, возвращающие значения свойств объектов БД — «официальный» пользовательский прикладной интерфейс. Подозреваю, что большинство администраторов БД обращается напрямую к системным таблицам за нужными им метаданными, но есть случаи, когда действительно проще воспользоваться INFORMATION_SCHEMA — например, для получения метаданных о внешних ключах в виде списка.
Недавно мне потребовалось написать сценарии удаления и создания внешних ключей, так что для выполнения этой задачи я сформировал запрос, основанный на статье двухлетней давности. Однако исходный запрос был ограничен применением внешних ключей из одного столбца, но, поскольку мне действительно хотелось лучше разобраться в применении INFORMATION_SCHEMA, пришлось копнуть глубже. В этой статье я поделюсь своими открытиями, включая и то, как создать «отсутствующее» представление INFORMATION_SCHEMA.
Новые особенности TSQL в SQL Server 2005: OUTPUT
SQL Server 2005 содержит обновления TSQL, которые упрощают повседневные задачи. Хотя функции @@IDENTITY и SCOPE_IDENTITY() все еще поддерживаются, вы, вероятно, сочтете выражение OUTPUT более удобным для получения сгенерированных вашими запросами значений.
Хотя генерация значений командами SQL удобна, она может вызвать затруднения, если созданные значения нужно узнать и использовать в дальнейшем. Например, широко распространенной практикой является определение таблицы со столбцом IDENTITY для заполнения значений первичного ключа во время команд INSERT. Иногда требуется знать значение IDENTITY сразу после выполнения команды INSERT — возможно, чтобы выполнить команды INSERT с дочерними таблицами. Также, когда таблицы имеют функции в качестве значений по умолчанию, например GETDATE(), бывает необходимо узнать эти значения после выполнения команды INSERT. Таким же образом команда UPDATE может явно указывать новое значение столбца как значение, известное только во время выполнения (например, установка текущего времени и даты функцией GETDATE() или расчет значения вычисляемого столбца).
Обычно для возврата наибольшего сгенерированного значения IDENTITY используется функция @@IDENTITY, SCOPE_IDENTITY() или IDENT_CURRENT(‘имя таблицы’). Но нужно понимать, что SELECT @@IDENTITY имеет область видимости на уровне сервера и может возвратить самое последнее значение из другой команды или даже из другой базы данных. Мне известны некоторые заблуждения по этому поводу: например, если поместить команды INSERT и SELECT @@IDENTITY в одну транзакцию, то SELECT @@IDENTITY возвратит правильный результат. Это неверно по нескольким причинам. Так, таблица может иметь триггер на INSERT, который вставляет значения в таблицу, имеющую столбец с IDENTITY. В SQL Server 2000 появилась функция SCOPE_IDENTITY(), возвращающая значение IDENTITY только для данной области видимости. В .NET Framework и ADO.NET разработчикам предлагаются способы получения значения IDENTITY с помощью кода приложения. Для дополнительной информации можно обратиться к статьям Knowledge Base 320301 (http://support.microsoft.com/kb/320301/ENUS/) и 320141 (http://support.microsoft.com/kb/320141/ENUS/).
Шифрование SQL Server 2005: ограничения шифрования и длины данных
Решение шифрования SQL Server 2005 имеет ограничения, и одним из них, составляющим проблему, является ограниченное количество открытого текста, которое может быть зашифровано. Я надеюсь, эта статья поможет разрешить затруднения.
Использование свойства IDENTITY и функции IDENTITY()
Свойство IDENTITY позволяет назначать числовым столбцам автоматическую нумерацию. Значения такого столбца формируются автоматически при вставке в таблицу новых строк в соответствии с величиной начального значения и приращения, заданными при назначении ему этого свойства.
Свойство IDENTITY можно назначить одному и только одному числовому столбцу в таблице. Столбец IDENTITY должен относиться к одному из типов данных: int, bigint, smallint, tinyint, decimal и numeric с масштабом 0, и у него должно быть ограничение, не допускающее значений NULL.
История секционирования в SQL Server: версии 6.5 — 2005
Горизонтальное секционирование позволяет разделять сущности базы данных на более управляемые части. Оно особенно эффективно в средах хранения данных и в средах очень больших баз данных (Very Large DataBases).
Например, у нас может быть секция, покрывающая данные по продажам текущего месяца, а остальные данные могут храниться в секции истории, доступной только для чтения. Такой подход позволяет нам оптимизировать каждую секцию с характеристиками DSS или OLTP соответственно.
Мы также наблюдаем большую масштабируемость, которую дает нам секционирование. С несколькими процессорами и отдельными дисками с файловыми группами SQL Server может работать с секциями независимо и рассчитывать агрегаты.
SQL Server 6.5
Логика секционирования должна быть реализована вручную каждым разработчиком. Каждый запрос на обновление должен быть направлен на нужную таблицу посредством специального кода. Это значит, что все ваши разработчики должны знать архитектуру секционирования.
Для получения данных вы могли создавать секционированные представления с помощью команд UNION. Это только упрощало получение данных, но каждый запрос проверял все базовые таблицы и, таким образом, не давал выигрыша в производительности.
SQL Server 7
Было возможным создание секционированного представления, которое направляло запросы получения данных нужной базовой таблице. Эта операция выполнялась с помощью ограничений CHECK базовых таблиц.
Например:
CREATE TABLE
dbo.Customers1
(
CustomerID char(5),
CompanyName nvarchar(40),
CONSTRAINT PKCustomerID1 PRIMARY KEY (CustomerID),
CONSTRAINT CKIDRange1 CHECK
(CustomerID BETWEEN 'A' AND 'GZZZZ')
)
CREATE TABLE dbo.Customers2
(
CustomerID char(5),
CompanyName nvarchar(40),
CONSTRAINT PKCustomerID2 PRIMARY KEY (CustomerID),
CONSTRAINT CKIDRange2 CHECK
(CustomerID BETWEEN 'H' AND 'QZZZZ')
)
CREATE TABLE
dbo.Customers3
(
CustomerID char(5),
CompanyName nvarchar(40),
CONSTRAINT PKCustomerID3 PRIMARY KEY (CustomerID),
CONSTRAINT CKIDRange3 CHECK
(CustomerID BETWEEN 'R' AND 'ZZZZZ')
)
GO
CREATE VIEW AllCustomers
AS
SELECT * FROM Customers1
UNION ALL
SELECT * FROM Customers2
UNION ALL
SELECT * FROM Customers3
GO
Если теперь мы проверим план выполнения следующей команды SELECT:
SELECT * FROM
AllCustomers
WHERE CustomerID = 'AAAAA'
Он не проверяет все базовые таблицы — он напрямую обращается к нужной.
Но если мы отключим ограничения:
ALTER TABLE
Customers1 NOCHECK CONSTRAINT CKIDRange1
ALTER TABLE Customers2 NOCHECK CONSTRAINT CKIDRange2
ALTER TABLE Customers3 NOCHECK CONSTRAINT CKIDRange3
Результаты получены из того же самого поведения, что и в версии 6.5.
Однако обращение к нужной таблице для команд модификации данных было невозможным.
SQL Server 2000
В SQL Server 2000 команды модификации данных также отправлялись нужной таблице. И снова для этого использовались ограничения CHECK. Итак, в предыдущем примере, если бы мы выполнили следующую команду перед отключением ограничений, она бы сработала:
INSERT INTO
AllCustomers VALUESÃ
('BBBBB', 'some company')
Однако, если бы мы запустили ее после отключения ограничений, то получили бы следующую ошибку:
Msg 4436, Level
16, State 12, Line 1
UNION ALL view
'CustomersPartitioned.dbo.AllCustomers' is not
updatable because a partitioning column
was not found.
В SQL Server 2000 также появились распределенные секционированные представления, которые используют триггер INSTEAD OF в представлении с операциями UNION для прямых обновлений нужной таблицы. Триггеры INSTEAD OF отличаются от триггеров AFTER/FOR тем, что они срабатывают перед ограничениями, позволяя нам избежать их нарушений.
SQL Server 2005
Основными недостатками в версии 2000 были:
·Накладные расходы по управлению, потому что каждая базовая таблица должна была управляться отдельно. Например, ограничения целостности данных должны были определяться для каждой таблицы.
·Так как каждая секция имела таблицу и индекс, оптимизатору запросов приходилось выполнять дополнительную работу (для каждой секции, которую покрывал запрос). Это приводило к действительно сложным и неочевидным планам выполнения.
SQL Server 2005 решает эти проблемы, потому что все секции принадлежат одной таблице. Файловые группы, использующиеся для того, чтобы все записи имели один и тот же ключ секционирования, помещаются в определенных дисковых пространствах.
Это дает нам упрощенную архитектуру разделов и упрощенную поддержку. Мы можем включать секции в таблицу или исключать их из нее, и эти операции являются всего лишь изменением метаданных, что позволяет избежать простоев, блокировок, использования журнала и т. п.
Также в случае, когда таблицы, входящие в соединение, являются «выровненными по хранилищу» (storage aligned) или «расстановленными» (colocated) (имеют одинаковые схему и функцию секционирования) и соединение выполняется по столбцу секционирования, мы получаем более эффективные планы выполнения и записи только из соответствующей RHS соединения, которые должны быть запрошены для каждой записи из LHS.
(Возврат на основную страницу)