вопрос возник при чтении langref. В части "CREATE DATABASE" этого нет, а в при описании команд управления правами доступа такая разница отмечается. Нагуглить в лоб не получилось.

Например

langref30.pdf, стр.494....Использование роли RDB$ADMIN в обычной базе данных
Для использования прав роли RDB$ADMIN пользователь просто указывает её при соединении
с базой данных. Он также может указать её позднее с помощью оператора SET ROLE.
Предоставление роли RDB$ADMIN в базе данных пользователей
Так как никто не может соединиться с базой данных пользователей,...

Пользовательская БД каким-то особым образом создается? в чем разница?

Кстати, еще один вопрос по CREATE DATABASE.

langref30.pdf, стр.87Необязательные параметры CREATE DATABASE
Необязательные предложения USER и PASSWORD задают, соответственно, имя и пароль
пользователя присутствующего в базе данных безопасности (security3.fdb или той, что
указана в параметре SecurityDatabase). Пользователя и пароль можно не указывать,
если установлены переменные окружения ISC_USER и ISC_PASSWORD.

Моя непонятка выделена жирным. Если я создаю БД на удаленном сервере, то о каком security3.fdb и о каких переменных окружения идет речь? По мне, если по-простому, если USER и PASSWORD отсутствуют, то в качестве владельца БД должен браться юзер, который выполняет команду (если у него есть права), но здесь про это нет ни слова.

Снимаю вопрос про security3fbd, она естественно одна, на сервере, пользователь должен ыбть там прописан.
Остается вопрос по переменным окружения. Какой пользователь является создателем БД, если он явно в команде не прописан?

И еще вопрос

Правильно я понял, что использование роли требует обязательное её упоминание в команде CONNECT или SET ROLE?

Я как-то привык (не обязательно по СУБД), что если пользователью назначена роль (или он входит в группу), то разрешения этой роли (группы) распространяются на этого пользователя по умолчанию . Например, есть две роли, одна дает право на SELECT из таблицы1, другая из таблицы2, и обе эти роли назначены пользователю. Я ожидал, что когда этот пользователь приконнектился к БД, то он сможет читать обе эти таблицы. В том числе и потому, что коли уж сервер умеет "складывать" разрешения пользователя с разрешениями указанной этому пользователю роли, то можно ожидать, что он умеет "складывать" все разрешения по всем ролям. Но нет, надо 1) роль обязательно явно указать, 2) что бы прочитать данные из одной и из другой таблицы, роль надо явно поменять.

По моему, это неудобно. Роли же уже всяко назначены, зачем пользователю их еще и явно указывать, какой в этом практический смысл? Я понимаю, что, когда роль указана явно, серверу меньше работы. Но, может быть, имеет смысл добавить режим, что б пользователь, приконнектившись к БД, вообще не парился указанием своих ролей, что-то типа CONNECT ... ALL ROLES?

Dimitry Sibiryakov,

спс!

Dimitry Sibiryakov,

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