Основное условие безопасности: обработка запросов производится хранимыми процедурами (в оракл так называются, в отсальных - хз), клиент только передает/отображает.
Описанное ниже - результат чтения ветки. Эту информацию я попытался скомпилировать, чтобы определить, на чем мне писать клиент к ораклу. Если есть заблуждения, неточности и прочее, прошу исправить.

Клиенты бывают двух типов:
1. Компилируемые;
2. Браузерные.

Компилируемые. Пишутся в делфи, билдере, вижуал С++ и др. Дополнительно для работы с СУБД ничего не нужно. Достоинства: кроме клиента больше ничего не нужно, иметь опыт программирования клиентов БД на delphi или c++. Недостатки: при изменении БД придется перекомпилировать (длябольшого клиента большие временные затраты). 

Браузерные. Бывают двух видов:
1. Реализуемые трехуровневой архитектурой;
2. Собственно "чистые" браузерные.

Реализуемые трехуровневой архитектурой. Пишутся в php. Дополнительно для работы с СУБД нужны веб-сервер и сервер приложений. Достоинства: ? Недостатки: см. Дополнительно, уметь настраивать эти дополнительные сервера.

"Чистые" (это я для себя так назвал). Пишутся на xml (в браузере преобразуется с помощью xslt в html страницу). Вообще ли пишутся xml вроде оракл сам генерирует, нужно только html страничку с формой написать? Дополнительно для работы с СУБД ничего не нужно. Достоинства: см. Дополнительно. Недостатки: если БД большая, увеличивается время обработки xml кода.

Мммм... то да не то 

"Компилируемые" - это не характеристика клиента аналогичная "браузерности" 
Куда впихнуть тут джава-апплеты, активикс? 


Как раз пхп -  это всё=таки двухуровневая ;)
Хотя, если расценивать как БД + Вебсервер + браузер - то ещё есть и четырёхуровневые )
И для пхп серверов приложений не существует.

Найду время - накопаю статьи по архитектурам и уровням.... Хотя, думаю, сейчас кто-то придёт и покажет некий фак(FAQ в смысле )

Gunslinger, 
Мне еще ни разу никто не смог показать, чем работа через ХП безопаснее работы напрямую. 
Есть права - и через ХП все разломаю, нет прав - и в гриде ничего не изменю.

Остальное - надуманное деление. Более часто клиентов делят на "толстых" и "тонких". Но и это достаточно условно.

Рекомендую разобраться, что за БД будет - реляционная или Веб/Интернет. Это две большие разницы.

chief39, 

Классическая трехзвенка: Сервер БД - сервер приложения - клиент. Так что на чем клиент - на "звенность" не влияет. 
2Gunslinger - сервер - не обязательно Веб.

Есть такая ситуевина: есть табличка с сотрудниками. И есть менеджеры, и надо дать возможность менеджеру редактировать сотрудников, но только тех которые подчинены ему, сотрудников других отделов ему редактировать нельзя и нельзя переводить сотрудника в другой отдел. Без ХП придется или извращаться с триггерами и кидать , или использовать фишки конкретной СУБД типа VPD Oracle.

Плюс ХП в том, что они могут иметь доступ к данным к которым у юзера доступа нет (например хранимка, может иметь доступ к словарю, к которому простому юзеру доступ давать нельзя).


Gunslinger, вообще клиенты делятся, на толстых - те которые сами осуществляют обработку данных, и тонких - которые только отображают результат, а всю обработку делает сервер.
Ты бы написал зачем это тебе все нужно.

Вы бы дали сначала определение, что такое "Реляционная БД", а заодно что такое "Реляция", а потом умничали.

Про трехуровневку я завернул, почитав "SQL. Полное руководство", второе издание авторы Вайнберг и Грофф. 
LSD, спасибо, а то в книге не расшифровывалось, что такое толстые и тонкие клиенты. Там и про 3ур мало было сказано, потому что книга не про то.
А причина, по которой я завел тему, частично описана в начале. Преподаватель сказала, что нужно написать клиент, который бы выдавал для конкретного пользователя конкретный интерфейс (для админа, обычного пользователя и тд.) и через него работать в БД (оракл 8.1.5). Мог сразу сесть за компилятор, но, как обычно, не люблю искать простые решения Вспомнив, что было сказано в книге задумался, масла в огонь подлило чтение ветки. Сейчас в голове каша, поэтому хочу с вашей помощью разобраться в вопросе, чтоб понять, какими путями возможно написание клиента и связанные с этим трудозатраты.
Дополнительные вопросы, которые меня интересуют:
1. Как для браузерного клиента реализовать защиту передаваемой от СУБД инфы, подтверждение аутентификации?
2.  Все что качается безопасности обоих решений (компилируемый и веб клиент).

chief39, буду благодарен. 

Это сообщение отредактировал(а) Gunslinger - 11.5.2007, 17:41

Gunslinger,

Ну тогда самое простое - разделить их на эти категории, по имени+паролю - вычислять кто и в приложении просто прятать/запрещать соответствующие действия. Если строго пирамида по правам и возможностям. У меня так. 4 уровня: только читатель - может смотреть, причем не все (новичок - оператор), оператор (заполнение и расчет конкретного дела), старший оператор (то же + печать отчетов + массовый пересчет), админ (все предыдущее плюс работа по заполнению справочников + может узнать кто какое дело когда рассчитал вплоть до каждой строчки по месяцам + ввод новых сотрудников с привилегиями). На уровне приложения. Ну и я. Админ на SQL-серваке, все прочие - под одну группу юзеров загнаны по правам. Ничего. 4-й год так живем.
Еще вариант: у всех одинаковый лоадер, котрый выясняет по имени и паролю права и в соответствии с ними загружает каждому свой вариант приложения (вытаскиваемое из БЛОБа на сервере, например, чтобы хитрее было).
Еще более ехидный (Тенцера идея) - все описания форм и т.п. - на сервере, лоадер их вытаскивает и организует. Но я это толком не понял, у него как-то в переписке ФИДО проскользнуло - "думаю все атрибуты приложения хранить на сервере - минимум проблем с апдейтом и разграничением прав, у всех только стабильный загрузчик." Но это студенту - неподъемно будет. Да и мне наверное тоже.

А вот если есть горизонтальные связки или не  пирамида - тут тяжелее. Проще всего, по моему, раскидать по группам на сервере, раздать соответствующие права, а на AccessViolation/Access Denied навесить стандартное: "Извините, не имеете права. Обратитесь к администратору". А триггеры вычисляют права в хитрых случаях.
Только по-моему такой уровень - уже не студенческий курсач.

LSD, 
Если нет перекрытия типа "2 начальника уровнем выше у 1 подчиненного" т.е. пирамида, то  
простейший вариант (без ХП и т.п.) - уже показал - права + "Извините, не имеете права. Обратитесь к администратору". При отсутствии горизонтальных связей - проскочит легко. И делается легко.
Ну а вообще при всяких таких усложнениях - каждый как ему нравится делает, и как задача позволяет. У меня например приятель обожает делать вьюшки разных сортов и в зависимости от прав - подсовывать нужную. Тоже вариант.

SergeBS, изначально хотел именно через общую форму с логином паролем. При этом в клиенте (который подумываю на борланд с++ писать) не хочу создавать формы для различных прав. В принципе ничего сложного, ненужные части интерфейса можно скрыть, но все же считаю это не красиво, да и дополнительный размер. А вот как тогда сделать, чтобы открывалось окно с нужным интерфейсом?
окно проверки прав пользователя--->пользователь вводит логин, пароль--->окно проверки прав пользователя отправляет их на сервер, где определяется, какой интерфейс предоставить пользователю---->на машине пользователя открывается соответствующий интерфейс.
Т.е. программно реализовано несколько интерфейсов, они хранятся на сервере. Но на чем написаны эти клиенты: компилированные или через веб?

з.ы. что такое пирамида, горизонтальная связка? chief39 вроде обещал, да пропал куда-то. 

Gunslinger, 
А по-другому никак.


Ну какая тебе разница? На чем умеешь, на том и пиши. Только "через веб" - идеологически неверное выражение, по-моему. "Веб" - интерфейс, а клиента пишут на VС, Perl, ...


Ну можно назвать деревом. Сверху коренной узел - главный (босс), от него - на замов, от замов - на нач.отделов (у каждого своя кучка) и т.д. Так вот и получим пирамиду управления.
А вот если окажется, что какой-то из листьев (исполнителей) имеет связь больше чем с 1 начальником (на него ведут 2 ветки), то получится горизонтальная связь этих двух начальников. Со всеми неприятными с точки зрения раздачи прав последствиями. И т.д.

SergeBS, понял. И еще вопрос, что такое БЛОБ на сервере, о котором ты упоминул?
Относительно того, на чем написан клиент. Наверное я действительно не на том внимание заостряю, но это от отсутствия нужных знаний. Можешь подсказать литературу про написание клиентов? 

Gunslinger, 

BLOB = Binary Large Object

Идешь в раздел "Литература" и смотришь. Я угадывать, на чем ты писать собираешься, не буду. 

Вся литература по дельфи. Такое ощущение, как будто на С++ клиентов никто не пишет.

Gunslinger, 

Пишут. У меня приятель, например. Если задача написать только клиента, то ничего особо отличающегося по хитростям не будет, независимо от языка. А если взять достаточно толстую книгу по Перлу/PHP например, то там это тоже будет. А еще есть книга "Базы данных и Интернет", вроде Фроловы авторы. Там если склероз не изменяет - не Дельфи.

Например так, создаёш таблицу пользователей:
 
И таблицу с правами на пункты меню (или чего у тебя есть там) по группам:

Дальше относиш каждого пользователя к определённой группе (groupid). При входе пользователя, считываеш права его группы:

И если у этого пункта меню (menuid) будет стоять доступ (is_access=1), то создаёш ему пункт в меню или рисуеш кнопочку.

А скрывать ничего не надо. В любом языке (ну может есть какие-то индивиды) можно создавать объекты программным путём. В борланде, на сколько я помню, есть процедуры CreateObject, в параметры которой ты заносиш необходимые значения для твоего бутона (размер, размещение и т.д.). Чтоб добавить новый пункт меню у объекта TMainMenu должно быть что-то типа InsertItem. Я думаю идею ты поймёш, а дальше всё можно найти в документациях.