Короткий ответ: Вы не можете .
Обычно разрешения на уровне сервера не распространяются на отдельные объекты в базах данных. Единственное исключение - это роль sysadmin, которую я настоятельно рекомендую вам использовать , а не для этой цели, поскольку вы, по сути, передаете контроль над всем экземпляром сервера каждому члену.
В качестве краткости вы можете использовать встроенные роли базы данных, чтобы избавить себя от проблем. Для доступа только для чтения обычно достаточно членства в роли db_datareader, если только у вас нет хранимых процедур, которые возвращают наборы данных, которые эта роль должна выполнять. Существует также аналогичная роль для модификации, db_datawriter, но она не распространяется на разрешение execute. Таким образом, вам нужно будет создать собственную роль для этого:
create role [DataChanger] authorization [dbo];
go
alter role [db_datareader] add member [DataChanger];
go
alter role [db_datawriter] add member [DataChanger];
go
grant execute to [DataChanger];
go
-- Now you can add your members. Here is a reader
create user [Domain\MyUser1] from login [Domain\MyUser1];
go
alter role [db_datareader] add member [Domain\MyUser1];
go
-- Writer
create user [Domain\MyUser2] from login [Domain\MyUser2];
go
alter role [DataChanger] add member [Domain\MyUser2];
go
Эти разрешения будут автоматически выбирать вновь созданные объекты без необходимости явного добавления новых разрешений после каждого изменения схемы.
Вам придется делать это в контексте каждой пользовательской базы данных, которой вы хотите управлять таким образом. Вероятно, вы можете создать задание агента SQL, которое будет запускаться периодически, и вносить эти изменения в любые пользовательские базы данных, у которых их еще нет (например, если база данных была восстановлена из более ранней резервной копии, или перенесена с другого сервера, или нового один был создан). Кроме того, поскольку вы не можете циклически проходить по базам данных в статическом коде, вам нужно будет обернуть его в динамический SQL и выполнить цикл по sys.databases, или, возможно, с помощью недокументированной sp_MSforeachdb системной хранимой процедуры. О, и не забудьте удалить все эти операторы go из динамического кода, так как они не являются частью SQL и распознаются только SSMS и sqlcmd.
P.S. Несмотря на это, я надеюсь, что вы не собираетесь управлять производственными базами данных таким образом. Я даже не знаю, с чего начать, насколько небезопасен этот подход.