Доброго всем времени суток, интересует такой вопрос: Предположим есть некая система, могопользовательская(трёхзвенка). В базе соответственно есть таблица с пользователями. Интересует вопрос как правильнее было бы организовать подключение пользователя в базе: на сервере заводить логин и пароль(который соответственно лежит в таблице в базе) и по нему пускать в систему или подключаться через какого-либо одного "пользователя", и под ним же работать с базой, а сервер приложений уже от имени этого пользователя выполняет все запросы к базе, селекты, хранимки и т.д? Как есть TRUE? Зараннее благодарен.

Ditry,

А если при подключении к серверу приложений, ему передавать логин/пароль пользователя БД, то сложнее будет сделать разграничение например прав доступа?

iscrafm,

Как раз и интересует как сделать правильно, пользователь работает с сервером приложений, а как быть с сервером БД? Под каким пользователем к базе лезет сервер приложений? под своим? или под тем логин/пароль которого задал пользователь?

softwarer,

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

softwarer,

Ваши мысли понятны, только имхо мы уплываем от начальной мысли. Попробую расписать: сейчас проектирую структуру системы(документооборота) Количество одновременно работающих пользователей думаю максимум пару тысяч(с запасом). От двухзвенки отказался сразу по причине:
1) "Сервера" должны взаимодействовать друг с другом(под взаимодействием подразумевается делегирование одного сервера другому части информации хранящейся на нём, например списка работников, документов и т.д. Слово сервера взято в кавычки, т.к под сервером понимаю именно сервер приложений, которые как раз и будут взаимодействовать друг с другом).
2) Должно быть несколько интерфейсов к системе, например linux, win и web версия... Понимаю что можно взять какой-либо кросплатформенный тулкит и наваять по принципу клиент-сервер, но всё-же... Вот тут возникает ещё один вопрос, как клиентскому приложению взаимодействовать с "сервером"(т.е в данном случае с сервером приложений, так получается), через какой-то протокол? изобретать велосипед?(конкретно для этой системы)

Такие вот мыслишки, поэтому и спрашиваю, раз клиент будет работать с "сервером", то как же самому серверу цепляться к БД. :)

Hauer,

Хм... а как?, например: клиент говорит серверу: "создай задачу", "дай мне данные", "верни мне все документы которые редактировались" и т.д В этом случае клиент отправляет серверу запрос, предположим(к примеру) так GET(DOCUMENT, 1234)... сервер из базы делает запрос select blabla where id=1234 blabla... и возвращает документ клиенту

softwarer,

автор1. Что за сервера? Какие у каждого функции, почему их обязательно несколько?
2. А зачем для взаимодействия серверов трёхзвенка?

Попробую обрисовать ситуацию, надеюсь ход мыслей будет понятен, скорректируйте, если что не так:

Предположим что пользователь работает с моей системой(также предположим, что система клиент-серверная, а не трёх-звенка как я планирую). Имеется несколько учреждений, которые работают с этой системой, причём у каждого учреждения своя база(своя база для того, чтобы не лепить всё в одну, об этом чуть дальше). Теперь предположим что пользователь(А) хочет отправить задачу другому пользователю(Б), который находится в другой базе(соответственно в базе пользователя(А), нет пользователя(Б) и наоборот). А задачу нужно передать, таким образом предполагается наличие какой-либо сторонней программки, которая берёт сообщение из одной базы и передаёт её в другую.

Я решил подойти так, что пользователи работают не с БД напрямую, а с некой прослойкой(сервером системы, назовём его для условности СДО, вот как раз и получается трёхзвенка. прим.). СДО может быть соеденён с другими СДО, территориально находящимися в разных частях города/страны, и делегировать ему скажем часть своих справочников, т.е Пользователь А, работая и открывая справочник пользователей видит не только пользователей своего сервера, но и пользователей, которые этому серверу делегировали другие СДО(делегирование предполагается задавать в настройках, кто кого видит, кто что может делать и т.д). При этом предполагается что система будет кросс-платформенной.

Теперь по поводу нескольких баз, думаю что было бы правильней для каждого учреждения иметь свою базу(не обязательно чтобы они физически располагались на разных серверах). Если все будут работать с одной базой то с одной стороны вроде как проще администрировать, а с другой это не очень гибкий вариант для расширения системы, да и железо нужно хорошее.

авторБизнес-логика уже не помещается в клиенте?
Предполагается наоборот, бизнес логика будет храниться на сервере БД, а СДО её использовать и предоставлять пользователям(и делегировать другим СДО, например головной офис запрашивает у пподразделения отчёт, сам отчёт-его select находится на сервере подразделения, а СДО головного офиса делегирована возможность его запускать, в головном просто нажимают кнопочку "Отчёт", СДО головного даёт запрос СДО подразделения - "Дай мне отчёт", СДО подразделения даёт запрос своей БД, та результат выборки, СДО подразделения эти результаты отправляет на СДО головного... там глядят... всё радуются... выдохнули)

Попробовал объяснить как смог(у меня это обычно плохо получается). :)