>softwarer,
>Запрос - будет доступен. И вернет только лекарства, разрешенные для "гостя" из аптек, разрешенных для "гостя".

Но объем данной информации очень большой и для одного клиента, не говоря уже о 1000 одновременно.

Функция row security не есть де факто для других типов баз данных. Проме жуточный уровень нивелирует это различие. Для этих целей использовал и битовое поле и дополнительную таблицу. Только клиентов группировал. И ограничение доступа групп к строкам.

Судя по тому, что коллеги говорят про Oracle, это уже не просто база данных, в неё встраиваются возможности операционной системы. Нужно ли это? Да и не все дороги ведут в ... Oracle.

C уважением, Владимир.

>Валентин,
>И еще замечание о кол-ве одновременных клиентов. Если под клиентами подразумеваются соединения в серверу БД, то почти для всех серверов это совсем не страшно, сколько их будет ...

А как же замечание Yo! про пулы соединений. Да и MSSQL также о них говорят. А реально сколько соединений в пуле.

И всетаки хочу получить ответ на свой вопрос.
Если информационная система по схеме клиент-сервер и не используя промежуточный слой для формирования сиквел предложений серверу данных, то с любой клиентской станции могу выдать на сервер запрос построения выборки из всех доступных строк очень большой таблицы и получить очень большую выборку. И допустимо, что это сделают одновременно 1000 клиентов.
Некоторые разработчики делают инстументы построения сиквел предложений у клиента.
Информация должна быть передана клиентам. Что происходит с пулами соединений и сессий. Они заняты?
В прототипе этот вопрос решается формированием сервером данных страницы ограниченного размера по запросу КриптоСервера, передаче ее КриптоСерверу и запрос конкретного клиента частично обработан. Сервер данных от клиента свободен.

С уважением, Владимир.

>Валентин
>На самом деле ради только этого я бы не писал промежуточное 3-е звено, которое будет собирать эти соединения, т.к. это не правильно. В коннекте каждого клиента могут быть объявлены различные переменные, временные таблицы, которорые для каждого должны быть "видны" только в его сессии.

Не совсем так.
Архитектура многозвенки в моем представлении.
Клиентская часть занимается графическим отображением информации из лоальной базы данных - DataSet.
Для её получения следует запрос ( идентификатор функции и параметры, но не сиквел предложение, сжатое, шифрованное с идентификатором сессии в понятии логики бизнес-уровня, у меня КриптоСервер) на следующий коммуникационный уровень. Это либо IIS, либо .Net Remoting сервер. Их сервисы выполняют примитивные функции: поддерживают физическую связь с клиентом на время обработки запроса и работают с абонентскими ящиками, выполняющие функции демфера и развязки. Кладут запрос в ящик и ждут ответа.
С другой стороны, абонентские ящики опрашивают КриптоСервера, получают запрос, дешифрируют и декомпрессируют, строят сиквел предложение и передают на сервер данных. Они ни как не ограничивают возможности серверов данных и их настройки и используют их наилучший, оптимальный вариант. Промежуточный слой КриптоСерверов осуществляет функцию посредника - что хорошо для клиента, хорошо и для КриптоСервера.
Их число определяется информационной нагрузкой. И значительно (в десятки раз) меньше числа активных клиентов.
Затем Крипто получают выборку, сжимают, шифруют и кладут в абонентский ящик.
КриптоСервер, абонентский ящик - это сервисы, и могут располагаться в любом месте вычислительной среды (на любом компьютере с установленноы Framework).
Повторяюсь, нагрузка на процессор операций сжатия и шифрования ничуть не меньше, чем выборка данных. А при достаточной длине ключа шифрования, может и значительно превзойти эту величину. Так что распараллеливание этих операций считаю разумным актом.
И подход к построению информационных систем становится типовым, и мало зависит от типа сервера данных (и в некотором смысле и от его функциональных возможностей - нет требуемой функции, реализуем на промежуточном уровне).
В прототипе строятся не пулы сессий и соединений (хотя и используют их, если это дает какое-то качество), но "пулы" запросов/ответов.

С уважением, Владимир.