Ваше приложение должно иметь отдельные идентификаторы и пароли для каждого пользователя. Учитывая это, у приложения нет причин иметь несколько идентификаторов пользователей при обращении к базе данных. Пока безопасность приложения реализована правильно, использование нескольких идентификаторов пользователей БД не дает никакой выгоды.
Предоставление каждому пользователю его собственного идентификатора пользователя БД, безусловно, было бы огромной болью, потому что это, вероятно, включало бы все виды особых случаев и исключений. Например, чтобы войти в приложение, приложение должно подтвердить идентификатор пользователя и пароль. Как это будет происходить, если у пользователя нет доступа к таблице паролей? Но если что-то нужно защитить от несанкционированного доступа, это таблица паролей. Таким образом, вам придется использовать один идентификатор пользователя для входа в систему, а затем убрать его и указать другой идентификатор пользователя. Вполне вероятно, что существуют другие таблицы, к которым данному пользователю может быть разрешен доступ в одном контексте, но не в другом. Бухгалтерия, вероятно, должна видеть общую сумму, выплаченную в зарплатах за год, но, возможно, они не могут видеть зарплаты отдельных сотрудников. Сотрудники могут иметь доступ к данным о своей выгоде, но не о других сотрудниках. И т.д.
Единственное исключение, о котором я могу подумать, это если бы вы позволили какой-то общий доступ к базе данных. В крайнем случае, если у вас есть экран, на котором пользователь может ввести произвольный запрос SQL, который вы затем выполните. В этом случае теоретически вы можете заставить приложение анализировать запрос и пытаться применять правила безопасности, но для этого потребуется, чтобы ваше приложение внедрило очень много знаний о SQL. В этом случае лучше назначить каждому пользователю свой собственный идентификатор пользователя БД и поместить правила безопасности в ядро базы данных.