LSVЧто касается безопасности, то она нужна не только в СУБД, но и на клиенте, например запрет редактирования/видимости конкретного поля в конкретной записи конкретным пользователем.
Нет. Принципиально неверно. Как только побеждает эта точка зрения, сразу начинаются крики "а вот наши хитрые пользователи ходят в базу мимо интерфейса, через sqlplus, и как нам им помешать?"

Безопасность должна быть в базе. Если поле невидимо - оно должно быть невидимо при коннекте этого пользователя к базе. И так далее. Точка.

LSVВ принципе согласен. Однако обеспечить это сложнее, чем в интерфейсе "спрятать/затенить".
Хм. Даже если так, "сложно" - никак не причина делать "плохо".

LSVТем более в 95% случаев для обеспечения безопасности этого достаточно.
Этого достаточно ровно для того, чтобы поднялись вышеозвученные крики и пошли стоны про "а вот давайте создадим запароленную роль" и прочее в ту же степь.

LSVПочему тогда никто не кричит, что практически во всех западных системах сделано всё именно в интерфейсе и на сервере ВООБЩЕ НИКАКОЙ ЛОГИКИ НЕТ. ?????
Не готов говорить про западные системы скопом. В OEBS практически все на уровне СУБД; в большинстве, подозреваю, почти все на уровне аппсервера (опять-таки - сервера).

LSVДелать всю логику на триггерах, вью и ХП конечно можно, но когда их (ХП и вью) станет 500..1000 то это рискует превратиться в неразгребаемую кучу кода. :)
Та же самая логика, разбросанная по самым непотребным местам клиентского кода, куда как менее разгребаема.

LSVИ потом....где я утверждал, что безопасность должна быть только на клиенте ? На клиенте она должна быть в дополнение к СУБД-шной .
Как только "вся безопасность в СУБД", на клиенте она становится тривиальной "не показывать того, что все равно нет". Это уже не безопасность, а эстетика.

LSVЧто касается sqlplus: а кто позволяет пользователям инсталить и использовать такие вещи ???
Вооот, начинается сказка про хитро...ых пользователей :)

LSVТогда впору обсудить стоит ли давать юзерам нативные логины/пароли ? И какие существуют другие варианты......
Угу. Обсудить "нафига создавать геморрой на пустом месте". Типа "мы не дадим пользователю пароля, пользователь поставит снифер" и прочая гонка вооружений совершенно на пустом месте. Там, где достаточно нормально сделать систему безопасности - и пусть пользователь притаскивает хоть sqlplus хоть SoftIce.

Заодно подумайте, каким образом без нативных паролей будет работать тот пользователь, который например составляет руководству отчеты в каком-нибудь Crystal Reports-е.

pkarklinЭээ... "нативные" - это значит логины\пароли на доступ к СУБД, а "не нативные" - это нечто созданное разработчиком? Если да, то зачем нужно второе, если есть первое?
Это одна из стандартных идей такой вот "клиентской безопасности". Звучит она примерно так: "а мы настоящий пароль от БД спрячем и никому-никому-никому давать не будем, так что никто не сможет подсоединиться к БД мимо приложения".

LSVодавляющее число систем почти не содержат логики на сервере
Однако, у них логика и не в клиенте, не в интерфейсе, как Вы писали выше. Соглашусь, мое утверждение формулировалось для двузвенки, для многозвенки надо было бы сказать "на любом сервере, чем раньше, тем лучше".

LSVИ потом....Чего Вы все так накинулись ???? Любой вор Вам скажет, что откроет большинство замков, кот. стоят в Ваших квартирах.... И что из этой логики следует ? ВООБЩЕ НЕ СТАВИТЬ ЗАМКОВ ????
В первую очередь из этого следует, что "дворничиха тетя Клава, которой из ее каморки видна дверь подъезда" не является удовлетворительной защитой.

LSVМожет лучше вместо "СЛОЖНО" и "ПЛОХО" обсудим "ЦЕЛЕСООБРАЗНО" ?
Незачем. Крики типа вышецитированного - про хитрых пользователей - раздаются регулярно. Не просто "иногда", а именно "регулярно". Соответственно, целесообразности в этом решении нет.

MGRКонкретный пример:
Только менеджер направления может проставлять поле кредитного лимита для конкретного клиента.
Причем некоторые сейлзы могут и не видеть этого клиента вообще.
Это, я бы сказал, слишком стандартный пример, для ответа даже не нужно привлекать большой арсенал. Могут не видеть - это row-level security. Могут проставлять - это проверка прав в процедуре простановки.

LSVДискуссия превратилась в обсуждение пословицы:
"Лучше быть богатым и здоровым, чем бедным и больным". (с)
Это с Вашей точки зрения так.

LSVА кто в таком случае назовёт хотя бы пару известных систем (кроме упомянутого OEBS), где вся безопасность лежит в СУБД ???
Вообще странный вопрос. Странный он чем: мы вообще говоря разработчики, в чужих системах копаемся постольку-поскольку, поэтому требование провести на коленке некий глобальный анализ ставит меня в тупик. Лично мне "из известных систем" приходилось ковыряться только в OEBS, да и его я бы с радостью пропустил.

LSVПричем желательно не в сервере приложений, а именно в СУБД.
А вот это уже вызывает подозрение, что Вам хочется не столько истины, сколько победы в споре. Поскольку я давным-давно упомянул, что формулировал утверждение для двузвенок и для трехзвенок готов его переиначить.