Нужна помощь в проектировании: в системе есть несколько ролей пользователей - менеджеры -

бригадиры
- транспортники
- и всякие другие

Есть документы, изменять которые могут лишь некоторые роли (к примеру Менеджеры и Бригадиры)
Как на уровне схемы развязать такое ограничение, чтобы в таблице Документы user_Id содержал ссылки только на эти 2 группы и при этом Из таблицы Документы можно было бы однозначно понять пользователь какой роли изменил запись?

у вас в вопросе есть такой подвопрос. в постргресе есть права, в том числе на доступ к таблицам и строкам от определённого юзера. То есть можно сделать таблицу и настроить права так, чтобы одни строки могли только читать или читать и изменять только менеджеры, а другие бригадиры и так далее. И если это учебная задача, то конечно это и спрашивают. Но если это реально приложение, то конечно решается на уровне СП с одним подключением в софте пишете ту логику, которая вам нужна, добавляете два поля дата и кто добавлял, изменял запись, делаете логику в приложении в каждом запросе кто и как может это всё менять.

Вы немного не в ту сторону пошли - мне не нужна row level security мне на уровне схемы данных нужно сделать связь с ролями пользователей (тупа поставить ссылки на 2 таблицы с поля user_id не проблема) но как-то криво оно выгдядит - нужно еще мостыки городить типа добавить поле роль юзера Я думал есть какие-то типовые развязки таких ситуаций на уровне схем данных

https://wiki.postgresql.org/wiki/Don't_Do_This#Don.27t_use_serial вам нужно 2 таблицы, это сотрудники, и должности, все, зачем на каждую должность делать таблицу? это дичь какая то

А по существу вопроса есть что-нибудь?

см. выше

Сотрудники в реальной а не в идеальной жизни к сожалению могут существовать в нескольких ипостасях

т.е ?

Бред, сотрудник + роль должно быть

Как ваше уже писали

я уже писал выше сотрудник+должность ну или +штатная единица когда менеджер+уборщик+крановщик :)

И как это решит проблемы подмены сотрудников в экстренных ситуациях?

назначается сотруднику дополнительная роль на период подмены

вы на это сообщение отвечаете

Вот и появляется у сотрудника 2 роли

Таблица "занимаемая должность": id user_id position_id from to

как и в реальной жизни, насколько понятно из вашего описания бизнес-процесса

пройдите в бухгалтерию, распишитесь в ведомости :)

Имея ссылку на сотрудника каким образом я могу понять от имени какой роли он сейчас выступает?

да, тоже об этом подумываю )

вы сформулируйте точнее

Ссылка на таблицу Сотрудники никак не говорит о том какую роль сотрудник исполняет при наличии у него более 1й активной роли и не ограничивает

да, поэтому делают в кадрах штатную единицу, человека привязывают к ставке и все это азы кадрового учета

поставьте 1с зуп и впитывайте

непонятно в вашем бизнес-процессе, какое у вас подразумевается отношение сотрудник-роль один ко многим или один к одному

один ко многим очевидно

И мне так кажется, но человек, как будто намекает на другое. Поэтому я его и не понимаю

один сотрыдник одновременно исполнять несколько ролей

его никто не понимают

я думаю Колумб переоткрывает кадровый учет.

Непонятно, вроде стандартная задача. О чем, вообще, обсуждение

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

ещё не забывайте надо учесть, что у человека меняются права со временем. То есть нужен лог истории, отдельная таблица, в нём пишет у кого какие права назначали, снимали. Ну замещение должности. Это всё решается на уровне сервера приложений в коде. Я удивлён, что это делают на уровне баз данных. И так как это реальный софт, логика будет достаточно запутанной.

вы хранить информацию будете в сервере приложений? это как раз типичная задача для БД, причем уже расписанная вдоль и поперек, выберите просто ваш вариант и все

нет, писать сложную логику обработки прав на нажимание всяких кнопок в реальном софте на сервере приложений. А хранить в базе. Нет, в книжках рассмотрены очень простые примеры, реально далёкие от учётных систем.

а кто-то про кнопки говорил?

а думаете они прямо в базе будут? Ну менеджеры, бригадиры?

конечно, а где им быть? О_о