Если посмотреть в летописи... то первыми СУБД - были иерархические СУБД, им на смену пришли сетевые... и только потом появился д-р Кодд со своими письмами... Почитайте, например, о комитете CODASYL... туда и СССР входил... Сейчас эту международную организацию, в которой было свыше 150 стран-участниц... просто забыли... а труды у них были просто титанические. Но все усилия этого монстра зачеркнули несколько страничек... описания реляционной модели. Но "история учит тому, что она ничему не учит"...
Я это, естественно, прекрасно знаю.
Давайте определимся - Вы знакомы с XQuery и его моделью данных? Просто иначе Вы не понимаете, какую именно иерархическую модель я имею в виду...
У меня очень поверхностное знакомство с XQuery... но если это иная иерархическая модель... то зачем её называть иерархической? С СУБД Cache я знаком (но не пользовался ей)... Есть какие-то принципиальные отличия у XQuery от COS? Если нет... то... обсуждать нечего.
Столь же алгебраичную и "декларативизируемую", как и реляционная. "Выросшую" из реляционной.
Т.е. это не откат куда-то назад, а виток диалектического развития. "Отрицание отрицания" после синтеза, на новом уровне.
Понимаете, основой для реляционной модели послужила математика (теория множеств, хотя почему-то до сих пор операторы работы со множествами не реализованы, как, собственно, реляционный язык). Всё, что было до и после реляционной модели, никакой основы под собой не имеют... Только лозунги... (за любую информацию, опровергающую мои слова, буду премного благодарен!)
Э-э-э... Зачем функции управления правами отдавать на уровень "бизнес-логики"?.. Поясните, пожалуйста... Чем ближе проверка прав к источнику домогательства... тем меньше... абортов.
Но в случае трёхзвенной архитектуры и веб-морд какой ныне основной режим? Описания пользователей и прав - обычными таблицами. Всё это разруливается на уровне серверной логики. А обращение к СУБД идёт под единственным пользователем, по внутреннему либо защищённому каналу связи между серверами приложений и сервером СУБД.
Вот теперь... всё понятно...
Чаще всего так - и причин тому можно увидеть две:
1) Система прав сильно зависит от СУБД, если есть желание иметь переносимость, то приходится надстраивать независимую от СУБД систему прав.
Илья Евгеньевич, у меня к Вам встречный вопрос... Вы стандарты SQL когда-нибудь видели? Вот
для примера и
здесь. Это ещё SQL-92... а потом был SQL-99, SQL-2008... И мне неизвестна ни одна реляционная СУБД, которая бы не поддерживала операторы управления правами пользователя... в соответствии со стандартом. Вы такие знаете?
2) Недостаточно гибкая, видимо, для многих случаев система прав СУБД. Например, нужно управлять правами на уровне операций, методов классов.
... и что?... Хоть на уровне отдельного атрибута... можно... И права на хранимые процедуры, и права хранимым процедурам... и права на VIEW... и на любой другой объект БД...
Так или иначе придётся делать вторую свою систему прав - потому что хранить эти права совместно с правами СУБД не получится...
Ну... конечно, конечно...
Исключение есть - MS SQL и доменная система, когда можно поддержать пользователя и хранение всего с ним связанного единым образом.. Но это опять же завязка на вендора...
А где этого нельзя?.. Система прав в стандарте... даёт возможность создать роль, для роли определить все необходимые права... А реальным пользователям давать права на роль или отбирать права на роль. И каждый пользователь... гарантированно не сможет сделать/увидеть то, что ему не положено. Если этого мало, то можно журнализировать любые действия пользователя... В чём проблема?
