Индексы

В SQL Server предусмотрено два типа индексов: кластерные и некластерные.

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

Некластерный индекс больше всего похож на указатель в конце книги. Для таблицы можно создавать таких индексов очень много (можно даже по нескольку для каждого столбца, но большой пользы это не приносит).

Безопасность sql Server

Процесс предоставления разрешений доступа выглядит очень просто:

1. Создать логин — учетную запись (имя входа) для подключения к SQL Server.

2. Затем создать пользователя базы данных, которому соответствует этот логин.

3. Предоставить пользователю необходимые разрешения.

Имя входа, под которым производится попытка соединения с экземпляром SQL Server, должно пройти следующие проверки:

Во-первых, оно должно доказать свою достоверность (аутентификация). Аутентификация — это процесс проверки права пользователя на доступ к тому или иному ресурсу. Чаще всего аутентификация осуществляется с помощью ввода имени и пароля. Когда имя входа отправляет пароль на сервер, оно тем самым посылает примерно такое сообщение: «Вот секретное слово, которое известно только тебе и имени входа, за которое я себя выдаю. Я знаю это секретное слово, а значит, я тот, за кого себя выдаю». Имя входа, доказавшее свою достоверность, называется авторизованным. После того, как достоверность имени входа установлена, для него можно вычислить действующие разрешения. SQL Server поддерживает два режима аутентификации: с помощью Windows и с помощью SQL Server.

Режим аутентификации Windows позволяет реализовать решение, основанное на однократной регистрации пользователя и едином пароле при доступе к различным приложениям (Single SignOn solution, SSO). Подобное решение упрощает работу пользователей, избавляя их от необходимости запоминания множества паролей и тем самым снижая риск их небезопасного хранения. Кроме того, данный режим позволяет использовать средства безопасности, предоставляемые операционной системой, такие как применение групповых и доменных политик безопасности, правил формирования и смены паролей, блокировка учетных записей, применение защищенных протоколов аутентификации с помощью шифрования паролей (Kerberos или NTLM). Т.е. используя данный режим, при проверке прав пользователя используется имя учетной записи пользователя Windows, под которой пользователь работает.

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

Принцип распределения прав доступа к объектам баз данных в большинстве серверных СУБД основан на наличии у каждого объекта базы данных пользователя-владельца, который может предоставлять другим пользователям права доступа к объектам базы данных. При этом набор объектов, принадлежащих одному и тому же пользователю, называется схемой. В SQL Server концепция ролей расширена: эта СУБД позволяет полностью отделить пользователя от схем и объектов базы данных. Теперь объекты базы данных принадлежат не пользователю, а схеме, не имеющей никакого отношения ни к каким учетным записям. Таким образом, схема становится механизмом группировки объектов, упрощающим предоставление пользователям прав на доступ к объектам.

Для упрощения управления правами доступа в большинстве серверных СУБД применяется механизм ролей — наборов прав доступа к объектам базы данных, присваиваемых некоторой совокупности пользователей. При использовании ролей управление распределением прав доступа к объектам между пользователями, выполняющими одинаковые функции и применяющими одни и те же приложения, существенно упрощается: создание роли и однократное назначение ей соответствующих прав осуществляется намного быстрее, нежели определение прав доступа каждого пользователя к каждому объекту. SQL Server позволяет создавать так называемые вложенные роли, то есть присваивать одной роли другую со всеми ее правами. Это упрощает управление не только правами пользователей, но и самими ролями, создавая, к примеру, сходные между собой группы ролей. SQL Server также поддерживает так называемые роли для приложений (application roles), которые могут использоваться для ограничения доступа к объектам базы данных в тех случаях, когда пользователи обращаются к данным с помощью конкретных приложений. В отличие от обычных ролей, роли для приложений, как правило, неактивны и не могут быть присвоены пользователям.