Зависит от того, будет ли имя пользователя / пароль для сервера SQL предоставляться пользователю, и будет ли это проблемой. Как правило, для внутренних приложений (в небольших организациях) можно доверять пользователям, не слишком входящим непосредственно в сервер sql. Если у вас есть слой промежуточного программного обеспечения (т.е. веб-сервисы), пароль может быть скрыт от пользователя.
Я предпочитаю использовать общий логин для БД и управлять пользователями в приложении. Даже если вы создадите имя входа в sql для каждого пользователя приложения, они все равно смогут подключиться напрямую, так почему бы просто не использовать общий вход в систему sql, которым проще управлять. Это, конечно, при условии, что все пользователи имеют одинаковый доступ.
Хорошей практикой, если пользователи потенциально могут получить прямой доступ к БД, является предоставление доступа только через хранимые процедуры, а не напрямую к таблицам, чтобы можно было выполнять только определенные действия. Избегайте написания бизнес-логики или проверок безопасности (кроме основных) в хранимых процессах.
Один из способов решения вашей проблемы - написать несколько веб-сервисов, которые проверяют безопасность и выполняют CRUD (через наборы данных и т. Д.), Но опять же, это зависит от приложения и среды.
В итоге, если у вас средний уровень или у всех пользователей одинаковый доступ, управляйте пользователем в приложении и используйте логин одного пользователя. В противном случае используйте логин для пользователя или роли.