папа Карло
Когда человек начинает орать что третье звено сакс и мастдай не сделав на нем ни одного проекта -- все что я могу сказать про этого человека что он ламер.

Хе хе - не согласен. Ламер - это человек широкого профиля по отсутствию знаний в некой области. Проф наоборот - человек с углубленными знаниями в некой области в определенной технологии. Так что если кто и орут, так это профы, а не ламеры - с чего ламерам то орать, когда они ничего не знают и не имеют собственных взглядов на проблему. В основном тут проблема я бы сказал чисто психологическая, а не отраслевая - человек выбрал технологию и естественно будет ее отстаивать при сравнениях с другими конкурирующими технологиями. Это просто надо перерасти. Как только до человека дойдет, что главное не технология, а правильный и мотивированный выбор соотвествующей технологии под поставленную задачу и любые вопросы "что лучше" отпадут сами собой.

Ученик
Если не секрет, поделитесь что за условия возникли в задаче, благодаря которым Вы не можете ее расчетную часть реализовать средствами СУБД ?
Мне просто интересно с практической точки зрения, как проектировщику БД.

папа Карло
А орут вот все равно профы :) Сидит например человек лет 7 в Delphi и когда слышит, что кто то на форуме обсуждает, что нехорошо батенька данные в парадоксных табличках хранить, страшно начинает возмущаться - типа как это не хорошо, работает же :) Или тот же пример с Access, в который по старинке многие "деды" программеры пытаются такие проекты всунуть, что волосы дыбом встают.

Ученик
Действительно - пока повода покидать стан 2-звенщиков нет :) Если уж так важна защита, то например самое примитивное решение - все таблицы закрыты на доступ, вся работа с выборкой и сохранением изменений ведется посредством ХП. А там что хотите, то и творите. - раздали гранты на выполнение ХП, а в них уже и определились кому что надо возвращать и кто что может изменять. Ну а все остальное Вами перечисленное элементарно решается запросами. Зачем огород с 3-звеном городить в данном случае не понятно.

папа Карло
Ну со мной понятно только одно - сначала я хочу видеть причины выбора методик решения задачи и насколько они оправданы. Если я вижу что проблема надумана или же вообще с другой оперы, то мне всегда интересно, с чего это ее еще хотят и усложнить. Ну давайте теперь все писать на 3-звенках, рассуждая что если они могут все, то остальное ничего не нужно. Берем ту же постановку кадров или бухгалтерии - тут явно без 3-звенки не обойтись, то то 1С теперь все на 3-е звено перекладывает, наверное вняло советам. Кстати не понимаю, чего Вас так и себя мое заявление вывело насчет того, что в данном случае 3-звенка не нужна. Она действительно не нужна, потому как проблема решается не с той стороны, поэтому и идет усложнение реализации. Я вообще то просто попросил рассказать проблему.

добавлю, что тебя с удовольствием возьмут в МС
Я надеюсь, что меня с удовольствием возьмут на работу любые работодатели, ценящие здравомыслие и практичность. Если в MS это ценят я могу работать и на них, если передо мной будут поставленны интересные задачи и достойным образом решен финансовый вопрос.

P.S. И не надо меня таким вот ярым 2-звенщиком изображать, я кстати с 89 года с ООП знаком и уже на TP 5.5 писал зачатки движка БД и визуально событийное программирование, а то прям создается впечатление, что я кроме SQL ничего и не видел, что на самом деле не так, я с SQL всего то с 98 года работаю.

Ученик
ну во первых ни кого я не агитирую за ту же ASA, я только в форумах сравниваю ее с другими СУБД. Ни разу не помню, чтобы я написал - "Народ бросаем все и айда на ASA или чего еще" (тот же PB) :)
Во вторых динамические фильтры как то далеко от бизнес-логики, эта задача уже ближе к логике клиента стоит, так как ни на целостность, ни на изменения содержимого БД они никак не влияют. Надеюсь папа Карло опять не взъестся, но опять подчеркну, что из за такого вот усложнять систему это просто смешно.
В третьих давайте рассмотрим Вашу постановку задачи, так сказать, чтобы понять, правильно ли присутствующие здесь ее поняли:
a) в системе поддерживаются роли пользователей и документы, которые доступны для просмотра и изменения их владельцам или же назначенным по разрешениям указанным ролям пользователей
б) для оперативного анализа информации требуется ее получение в неизвестном кол-ве разрезов, но опять же с учетом установленных прав пользователей

Если я все правильно описал, то логически вытекает, что задача то двух- уровневая, то есть решается одновременно в двух уровнях: клиентской и серверной части.

Все описания прав пользователей и их привязки по юзерам БД естественно храним в БД.

Всякие динамические запросы должен сам клиент генерить, с чего это вдруг с него работу на сервер перекладывать, которую он выполнять и должен.

Как все это организовать тоже пока проблем не вижу - закрываем на просмотр таблицы, создаем на них вьювер, в котором по User_ID() не забываем отобрать то множество информации, которое пользователю полагается видеть. Ну а клиент уже может генерить как ему вздумается скрипты на эти вьюверы и радоваться жизни.

P.S. Вот так вот :)