>поэтому есть желание дать девелоперам только право на создание, модифицирование и удаление СП и функций
Вот с первым проблем нет: лучше создать роль, например Developers, и назначить ей права
GRANT CREATE FUNCTION, CREATE PROCEDURE TO Developers
Правда, т.к. ваши девелоперы не члены db_owner, то если они при создании не будут указывать владельца dbo, то будут автоматически становиться владельцами создаваемых процедур. Т.е. придется решать этот вопрос административно.

А вот ALTER и DROP объекта могут выполнять владелец и члены групп db_owner и db_ddladmin. Владелец и db_owner вам не подходят(владельцем всех объектов вы хотите видеь dbo, ведь так ?, ну а db_owner - это слишком много прав). Остается db_ddladmin - правда у члена роли будет право выполнять абсолютно все команды DDL.


>чтение, удаление и упдей записей в выбранных таблицах в неймспейсе dbo
Тут совсем все просто: создается роль и наделяется сответсвующими правами.

IMHO
Может быть надо ставить вопрос шире. Организовывать что-то вроде тестовой/девелоперской базы, в которой можно очень многое. После отладки процедур наделенные соответсвующими правами люди переносят код в реально работающую базу.

Либо девелопер на стадии отладки является владельцем процедуры и после окончания откладки опять же специальный человек меняет владельца процедуры, отбирая таким образом права у девелопера.

Вообщем вопрос не простой и уникального рецепта ршения только с помощью встроенных средств IMHO нет.

Ещё раз все попорядку
Вы хотите, чтобы в рамках одной базы

1. Владельцем всех объектов был dbo.
Для того, чтобы создавать объекты, принадлежащие другому пользователю(читай dbo), роль Developers должена быть
- dbo(не подходит, т.к. у нас не один пользоватеь а группа)
- членом роли db_owner(подходит, почему бы и нет)
- членом роли db_ddladmin (тоже подходит)


2. Роль Developers не имела права на команды ALTER и DROP на некоторые таблицы
Обычно права на команды ALTER и DROP для объекта внутри базы имеют
- владелец объекта(в нашем случае это всегда dbo, см.п.1, не подходит)
- член роли db_owner(ага! значит Developers сюда пускать нельзя)
- член роли db_ddladmin (и сюда тоже)

3. Роль Developers имела права создание процедур и функций для владельца
См.п.1

4. Роль Developers имела права редактирование процедур и функций
См.п.2

Т.е. налицо явное противоречие: вы хотите чтобы в отношении некоторых объектов(процедур и функций) роль Developers вела себя как dbo, а в отношении других(таблицы) - как обыкновенный пользователь. В рамках одной базы поставленные вами условия IMHO выполнить невозможно.

Возможные решения
1. В рамках одной базы: разрешить членам Developers создавать процедуры и функции и владеть ими. Тогда они смогут редактировать и удалять их, не имея членства в db_owner и ddl_admin, что в свою очередь не позволит им(если не будут даны права) изменять структуры таблиц.

2. В рамках двух баз: в одной базе роль Developers входит в роль db_owner. В этой базе разрешено(!административно!) создание только процедур и функций. Во второй базе находяся таблицы и здесь аналогичная роль Developers имеет строго назначенные права, исключающие возможность изменения и/или создания объектов.
Такое решение потребует
- чтобы пользователи были продублированы в обеих базах
- чтобы обращение к объектам второй базы из процедур первой базы происходило с указанием имени базы (это в свою очередь может повлечь наверное проблемы на стадии промышленного внедрения, когда имя базы придется менять)
- .....

3. Организация работы разработчиков с базой не напрямую, а через средства 3-их фирм, где имеются возможности отслеживания внесенных изменений.

4. Какие-то административные решения о порядке изменения критических объектов

5. .....

2папа Карло
Так я вам про что и толкую

Есть права на структуру объектов и на их содержимое.
Нет DENY на ALTER и DROP ! Запрет/разрешение на ALTER и DROP определяется членством в роли или фактом владением объектом (см п.2 моего предыдущего сообщения и вывод)