Какие именно данные приложения следует хранить в базе данных

С появлением усовершенствованных в отношении производительности и более гибких ядер баз данных, как, скажем, в Microsoft SQL Server 2005, размывается граница между теми объектами, которые следует хранить в базах данных, и теми, которые хранить в них не следует. Раньше базы данных хорошо подходили для хранения только структурированных данных. Однако благодаря недавним достижениям в сфере технологий механизмов баз данных становится все более простым и более выполнимым хранение в базе данных и неструктурированных данных, таких, как документы и изображения. Хранить ли в базе данных все или только некоторые из данных внешних приложений, зависит от того, как эти данные используются.

В этой лекции рассказывается о том, как хранить настройки приложений в базе данных. Кроме того, вы узнаете, как манипулировать пользовательскими настройками, сохраняемыми в базе данных. Поскольку XML представляет собой естественный способ хранения иерархических данных, приводятся также подробные сведения об XML-данных. В завершение рассматривается хранение в базе данных больших объектов, для чего обычно используются отдельные файлы.

Где хранить настройки приложений

В программировании на платформе .NET для хранения данных приложений обычно используются XML-документы (обычно с расширением . config ). Если необходимо, чтобы приложение демонстрировало различное поведение в разных ситуациях, возникают сложности. Необходимо либо предусмотреть это в файле конфигурации, либо рассмотреть вариант с применением архитектуры параметров, управляемых данными, при которой для настройки приложения используются данные. Если вы выберете последнее решение, то база данных будет естественным местом для хранения данных, которые управляют настройками приложения.

Прежде чем выбрать модель управления настройками с помощью данных, следует сначала учесть некоторые доводы в пользу использования в приложении конфигурационных файлов. Если ваше приложение не нуждается в базе данных для какой-либо еще функции, возможно, не стоит включать в приложение базу данных только для параметров приложения. Аналогично, если приложение нуждается в параметрах уже в процессе загрузки, а на этом этапе процесса база данных обычно недоступна, то конфигурационный файл будет более естественным решением. (Раньше параметры приложения в подобных ситуациях обычно хранились в реестре Windows, но сейчас они чаще хранятся в конфигурационных файлах приложения.) Одним из главных преимуществ хранения параметров конфигурации приложения в файле является то, что этим файлом с легкостью могут манипулировать пользователи. XML-файл можно редактировать в Блокноте, поэтому любой пользователь может изменить параметры. Если необходимо предотвратить просмотр или изменение уязвимых настроек пользователями, то файлы конфигурации можно зашифровать.

Несмотря на недоступность в процессе запуска приложения, хранение параметров приложения в базе данных может быть выгодным. В базе данных можно управлять доступом к параметрам при помощи политики безопасности базы, в том числе, используя шифрование в SQL Server 2005. Это не даст пользователям, которые, возможно, не вполне представляют себе последствия сделанных изменений, возможности изменить параметры. Если вы используете какой-либо вариант ролевой модели безопасности (см. лекции 2-3), можно контролировать, кому предоставляется возможность изменять отдельные параметры приложения. Сохранение параметров приложения в базе данных будет также очень полезно в распределенных приложениях. Таким образом, вы сможете хранить такие разные параметры, как часовой пояс или офисные правила, в одном месте - базе данных. Эти параметры можно настроить так, чтобы приложение хранило различные версии настроек для разных пользователей или групп пользователей, а контролировать параметры смогут сотрудники, имеющие достаточную квалификацию. В табл. 1.1 показаны преимущества, предлагаемые каждым из двух вариантов.

Совет. Если вы хотите использовать преимущества, предоставляемые хранением параметров в базе данных, но не хотите утяжелять клиент полнофункциональной базой данных, подумайте о реализации хранения параметров приложения в базе данных средствами программы Microsoft SQL Server 2005 Express Edition, которая распространяется бесплатно, или Microsoft SQL Server 2005 Workgroup Edition, стоимость которой является убедительным доводом в пользу ее применения для небольших реализаций.

Как вы уже поняли из сравнения двух методов в табл. 1.1, следует выбрать тот вариант, который лучше подходит для вашего приложения. Не существует однозначного ответа на вопрос, где хранить параметры приложения - в базе данных или в конфигурационном файле. Взвешенно оцените свои потребности и среду и используйте приведенную здесь информацию для принятия такого решения, которое наилучшим образом соответствует требованиям вашего приложения.

Где хранить пользовательские настройки

Часто приложению необходимо хранить информацию о предпочтениях пользователей. В веб-приложениях это обычно реализуется при помощи файлов cookie (небольших текстовых файлов, которые хранят информацию о пользователях), но ввиду возросших требований к обеспечению безопасности в интернете такой подход может оказаться проблематичным. При использовании некоторых видов идентификации пользователей пользовательские настройки можно хранить в базе данных. Это позволит управлять этими настройками, не обращаясь к клиентскому компьютеру. В базе данных можно хранить самые разные пользовательские настройки. Эти настройки можно хранить в виде XML-данных, которые обеспечивают максимальную гибкость (о хранении XML-данных будет рассказано далее в этой лекции). Можно также использовать стандартные методы работы с данными для отслеживания пользовательских настроек. Если для хранения пользовательских настроек используется SQL Server, то пользователь может переносить их с одного клиента на другой.

Реализация таблицы пользовательских настроек

1. Определите, какие параметры вам необходимо хранить. Хотя в базе данных приложения можно хранить все пользовательские настройки, важно решить, какие параметры необходимы для обеспечения функционирования приложения в особых случаях, а какие параметры должны быть доступными при любом входе пользователя в систему, с какого бы клиента этот вход не выполнялся.
2. После того, как вы определите, какие параметры нужно хранить, разработайте необходимую для хранения параметров таблицу. табл. 1.2 представляет собой примерный проект таблицы для управления пользовательскими настройками в базе данных.

   Таблица 1.2. Примерный проект таблицы для хранения пользовательских настроек

   Имя логического столбца	Назначение
   Идентификатор пользователя	Хранит уникальный идентификатор пользователя, который может использоваться для идентификации и возврата пользовательских настроек. Тип данных этого столбца будет зависеть от реализации идентификаторов пользователей в приложении.
   Дата добавления пользователя.	В этот столбец записывается дата добавления Первая запись о пользовательских настройках обычно создается после добавления пользователя.
   Дата обновления настроек	Помогает управлять активными пользователями и проверять актуальность их настроек. Обновление данных часто является более важным, чем их создание.
   Последний вход в систему	Сохраняет информацию о последнем входе пользователя в систему. В некоторых случаях эта информация дублирует информацию в столбце Дата обновления настроек. В зависимости от реализации столбца даты обновления, можно отказаться от данного столбца и использовать только столбец Дата обновления.
   Столбец или столбцы для хранения пользовательских настроек	В этот столбец записываются пользовательские настройки, которые необходимо сохранить.

   Существует две распространенных реализации столбцов пользовательских настроек. Первая реализация - реляционная. Каждая настройка в этой реализации хранится в отдельном столбце таблицы. С этим решением связана следующая проблема: чтобы добавить дополнительную настройку, придется расширять таблицу путем добавления столбца. Второй вариант - все пользовательские настройки хранятся в одном столбце. С появлением XML можно использовать XML-документ для хранения нужных настроек либо в столбце TEXT, либо в столбце с типом данных XML; об этом речь пойдет далее в этой лекции.
3. Затем продумайте, какие объекты данных необходимы для извлечения и управления таблицей пользовательских настроек. Вот что для этого нужно:
   • Хранимая процедура Insert. С помощью этой процедуры добавляется начальная запись пользовательских настроек. Часто это делается при добавлении пользователя, поэтому данную процедуру можно объединить с процедурой добавления пользователя.
   • Хранимая процедура Update. Обновляет запись пользовательских настроек. Эта процедура часто вызывается для управления пользовательскими настройками в приложении.
     Важно. При отслеживании часто изменяющихся данных в таблице пользовательских настроек администратору придется активно наблюдать за производительностью и при необходимости регулировать работу реализации. Это особенно верно, если пользовательские настройки обновляются не просто для входа в приложение и выхода из него, но также и для других событий.
   • Хранимая процедура Delete. Предназначена для удаления записи пользовательских настроек. Эта операция, как и операция вставки, может выполняться в составе процедуры удаления пользователя. Однако вам нужно будет выполнить эти две процедуры по отдельности, если придется поддержать концепцию, например, сбросить пользовательские настройки на значения по умолчанию.

Где хранить XML-документы

Несколько лет назад XML-документы были новым веянием, но сейчас они уже стали привычными. Весьма вероятно, что вы уже видели и применяли XML-документы для настройки конфигурации и других задач в приложениях, с которыми работали. В SQL Server 2005 и Microsoft .NET Framework XML-документы широко используются для настройки параметров конфигурации и реализации других функций, таких, как службы интеграции SQL Server Integration Services (для которых XML хранятся в файлах .dtsx ) и службы составления отчетов SQL Server Reporting Services (данные XML хранятся в файлах с расширением . rdl ). XML имеет ряд преимуществ, не последнее из которых - гибкость при изменении требований к конфигурации приложения. Как было отмечено ранее, файлы XML также дают возможность пользователям приложения легко изменять параметры конфигурации.

XML также прекрасно справляется с хранением иерархических данных. Вот несколько примеров иерархических данных: магазинные чеки, спецификации материалов и счета за медицинское обслуживание. Все они включают родительские записи с дочерними записями разных уровней. Извлечение полных наборов этих данных из механизма базы данных может быть затруднено, но XML хранит данные в форме, позволяющей легко просмотреть данные. Поскольку XML очень эффективен и все более широко используется, разработчики компании Microsoft включили в SQL Server 2000 и SQL Server 2005 тип данных XML, а также реализовала особый механизм оптимизации и операторы T-SQL для управления XML-данными.

Примечание. XML-документы уже широко применяются для совместного использования информации внутренними и внешними потребителями в различных сферах бизнеса. В частности, приложения, используемые в здравоохранении, используют XML-схемы для организации совместного использования данных внешними партнерами и внутренними системами лечебных учреждений. Программный пакет Microsoft BizTalk Server 2006 разработан для управления бизнес-процессами и интеграции в подобных ситуациях и для этой цели использует XML-документы.

Поддержка XML в SQL Server 2005

В SQL Server 2005 разработчиками Microsoft в механизм базы данных были добавлены несколько новых специфических XML-функций. Эти усовершенствования позволили облегчить доступ к XML-данным и манипуляции с ними. Ниже перечислены некоторые из таких усовершенствований:

• Собственный тип данных XML
• Поддержка XML-схем
• Возможность использования запросов XQuery к XML-данным, которые хранятся в столбцах с типом данных XML и в переменных
• Возможность индексировать XML-данные, которые хранятся в столбцах XML
• Поддержка языка манипулирования данными XML (XML-DML)
• Усовершенствование существующих функций SQL Server 2000 для работы с XML, в том числе добавление ключевых слов OPENROWSET, FOR XML и OPENXML