REVOKE UPDATE (Ocenka) ON

Рассмотрим еще несколько моментов, связанных с предоставлением разрешений:

• 
  в большинстве реальных задач используются десятки и даже сотни таблиц и других объектов базы данных. Предоставлять каждому пользователю разрешения на каждый из этих объектов очень неудобно. Если есть возможность, постарайтесь использовать разрешения на уровне схемы или всей базы данных. Часто упростить предоставление разрешений могут и встроенные роли баз данных (db_datareader и db_datawriter);
  
• 
  существует общий принцип: не стоит обращаться из клиентского приложения к таблицам базы данных напрямую. Для изменения данных лучше использовать хранимые процедуры, а для запросов на чтение — хранимые процедуры или представления (при этом хранимые процедуры предпочтительнее). Причина проста: вы избежите внесения изменений в клиентское приложение, если потребовалось поменять структуру вашей базы данных (например, какая-то таблица поделилась на текущую и архивную или добавился новый столбец). Это следует помнить и при предоставлении разрешений. Отметим также, что при помощи хранимых процедур можно очень просто реализовать дополнительные проверки в добавление к обычным разрешениям;
  
• 
  SQL Server позволяет настраивать разрешения на уровне отдельных столбцов. На практике лучше не пользоваться такими разрешениями из-за падения производительности и усложнения системы разрешений. Если пользователю можно видеть не все столбцы в таблице (например, ему не нужны домашние телефоны сотрудников), то правильнее будет создать представление или хранимую процедуру, которые будут отфильтровывать ненужные столбцы;
  
• 
  в SQL Server 2005 появилась кнопка Effective Permissions (она расположена на вкладке Permissions). Эта кнопка позволяет посмотреть итоговые разрешения для пользователя или роли базы данных (поскольку разрешения от разных ролей базы данных, назначенных этому пользователю, суммируются).