hVosttnovexelfНет там проблем.

Есть. И называется она: логика в БД.
А когда потребуется связать более одной БД и систем под одной учёткой, вот тогда начинаются пляски, типа тупо добавить роль это 2 мес. работы и больше ляма. Не шучу.
Нет проблем, если денег овердахуа и раздутый штат бездельников.

Логика в БД не для всех проблема. Для меня это не проблема.
Когда требуется связать более одной БД, у меня лично возникают вопросы - зачем???
Меня учили, что в БД должны быть механизмы поддержания целостности, форенкей. А БД должна быть нормализована минимум до 3 НФ.
И поэтому, когда нужны в одной БД данные другой, то я выбираю реплики нужных данных или ETL.
На крайней случай есть варианты сделать и прям в лоб.
Но смысл?
Можно найти какие-то исключительные ситуации, когда то или иное решение будет в выигрыше/проигрыше, но тогда нужно выбирать соответственно лучшее. О чем речь то? Я лично выберу подходящее. Но 2х звенку исключать только потому, что а вдруг ..., не буду.

Про деньги упоминать вообще смысла нет, если у нас только одна цифра и та не понятно откуда взята.

alex55555novexelfНа сервере БД заводится логин с конкретным паролем, которые выдаются пользователю. Пользователь хранит логин/пароль в голове. Либо аутенификация/авторизация идет через керберос/домен. Но даже в этом случае пользователь хранит пароль от учетки в голове, только теперь учетка другая.
В БД создаются необходимые хранимые процедуры, функции и представления.
В БД создаются роли/группы, которым выдаются конкретные права на запуск хранимых процедур, функций и просмотр представлений.
Доступ к таблицам пользователю не выдается.
Объекты БД используются приложением.
Если пользователю приложения выдается доступ к какому-то объекту по долгу службы, то он и в БД увидит тоже самое, но не больше и нет тут ни какой проблемы.
Не должен кто-то видеть все записи, а должен быть только поиск, значит нужно сделать соответствующую процедуру, которая выдаст только одну запись. Не должен видеть какие-то записи, значит делается так, чтобы они были видны.
Нет там проблем.
Это был озвучен подход типа "всё в хранимых процедурах". Я согласен, теоретически оно работает. Но ещё раз повторюсь - что-то сложное вы застрелитесь рисовать. Простой пример из реальной практики - гуру ваял вот так же свои шедевры в БД и делал это очень долго , потом тупо прикрутили тривиальный аналог на VB и студент с нуля во всём разобрался сам за неделю и как из пулемёта начал выдавать фичи, которые гуру делал неделями.
Это работает практически. Почему Вы решили, что у меня будут какие-то проблемы с реализацией чего-то сложного? Код он и в африке код, его все равно писать нужно.
Если кто-то что-то делает долго, то это только отдельный случай и делать выводы о всех других ситуациях смешно.
Все равно, что сказать, один человек пробовал груши и ел их так медленно..., поменяли груши на яблоки и другой стал их есть так быстро :-)
Что за волшебство прикрутили на VB - не понял.

alex55555maytonНа втором шаге ты читаешь как устроен Oracle VPD (Virtual Private Databases), или Oracle OLS (Label Security)
Ну так а кто конфигурить-то это всё будет? Я же писал кейс - юзер должен галочками. Всем здесь тупо лень читать?

Вопрос же был про хранения пароля.

Что должен сделать пользователь галочками?
И как это волшебство реализуется? (в 3х звенках)

alex55555novexelfКод он и в африке код, его все равно писать нужно.
Если кто-то что-то делает долго, то это только отдельный случай и делать выводы о всех других ситуациях смешно.
Не смешно. Например надо дёргать сторонние системы, и как? Всё из базы? Веб-сервисы и очереди, ftp и custom-протоколы...

А например не надо. Ну вот не надо и что тогда?
А например надо рисовать 3d объекты на экране, танковый бой вести, чай танчики тоже в БД пишут/читают.
Есть абстрактный пример, а есть конкретный.
Хотите обсудить ваш конкретный, расскажите о нем.
Пока что вы хотите рассказать, что в некотором подходе только минусы, "ок" - путь по вашему будет так.
Я лично знаю, что любой подход имеет право на существование.