Как лучше построить безопасность БД ? (Oracle)

← →
ANB © (2005-05-25 16:05) [0]

Знаю несколько способов :
- Через гранты раздаем права. Тонкая настройка (выборка только части записей или сложные условия) - на клиенте. Хуже еще не видел, легко ломается, хотя можно усложнить взлом, например, шифруя пароль.
- Доступ только на вьюхи, изменения через хранимки - жутко неудобно каждый раз переправлять эти хранимки. И блокирутся возможность выполнять обычные DML.
- Доступ только на вьюхи, изменения через instead of триггера + хранимки для удобства - так еще не видел, соответственно прокомментировать не могу.
Все комментарии, ессно, имхо.
Кто еще с какими схемами защиты сталкивался и какую может посоветовать ?

← →
Sergey13 © (2005-05-25 16:10) [1]

>Как лучше построить безопасность БД ?
Безопасность от чего?

← →
evvcom © (2005-05-25 16:21) [2]

> - Доступ только на вьюхи, изменения через хранимки - жутко
> неудобно каждый раз переправлять эти хранимки. И блокирутся
> возможность выполнять обычные DML.

Я делаю и чтение, и запись через хранимки. Неудобства не испытывал пока. Блокируется DML? Или все же DDL? А зачем DDL юзеру?

← →
ANB © (2005-05-25 16:39) [3]

> Блокируется DML?
- есно. Если стоит защита с изменениями через хранимки, а нужно будет выполнить изменение в базе не из клиента, а ручками, то нужно и юзать тогда эти процедуры. А прямые апдейты будут доступны, во первых - только программисту, во вторых - ими можно поломать базу.

← →
evvcom © (2005-05-25 16:57) [4]

> А прямые апдейты будут доступны, во первых - только программисту,
> во вторых - ими можно поломать базу.

Ах вот, что ты имел в виду! А зачем тогда давать юзеру выполнять прямые апдейты? Не надо! Пусть это и будет доступно только программисту и админу. А чтобы не поломать базу, используй констрэйнты и тригера.

← →
ANB © (2005-05-25 17:06) [5]

> evvcom © (25.05.05 16:57) [4]
- работал я с системой, которая была построена по такому принципу. Только автор очень не любил триггера (mutating-ов боялся), принципиально не делал каскадное удаление и вырубил все внешние ключи, так как решил сделать возможность ссылаться на несколько таблиц, а ссылочную целостность проверял в хранимках.
За несколько лет эксплуатации сопровождающие ПРОГРАММИСТЫ, не всегда знающие, а иногда и не имеющие возможность вызвать соответствующие ХП, такого наворотили прямыми DML в базе . . . Мусора было, хоть отбавляй.

← →
Danilka © (2005-05-25 17:09) [6]

Наша контора работает по третьему варианту. Довольно удобно.

← →
Danilka © (2005-05-25 17:10) [7]

[1] Sergey13 © (25.05.05 16:10)
Ну, например, какой-то юзер должен видеть только определенную группу клиентов в базе.

← →
evvcom © (2005-05-25 17:14) [8]

> Только автор очень не любил триггера (mutating-ов боялся),

mutating не так уж и часто встречается. Есть способы их обойти, сам еще не пробовал, но принципы нашел уже.

> принципиально не делал каскадное удаление

я тоже не делаю

> и вырубил все внешние ключи

а вот это зря, не побоюсь сказать это без имхо

> так как решил сделать возможность ссылаться на несколько
> таблиц

у тебя Oracle какой? Если 9 и выше, то можешь для этого использовать объектные решения.

> такого наворотили прямыми DML в базе

вот для этого и придумали ссылочную целостность и тригера. Не советую повторять эти ошибки.

← →
evvcom © (2005-05-25 17:18) [9]

> Наша контора работает по третьему варианту. Довольно удобно.

Не пробовал, но думаю, это ничем не отличается от 2 варианта.

← →
Danilka © (2005-05-25 18:42) [10]

[9] evvcom © (25.05.05 17:18)
Ну, самое весомое отличие это то, что можно делать апдейт вьюхи по каким-то условиям, когда сразу апдейтятся несколько записей. С ХП это повторить уже сложнее. И вообще, получается для клиента такая вьюха неотличима от таблицы, и всю работу с ней можно строить как с таблицей.

Привык к такому варианту работы, а как столкнулся с проблемами в использовании instead of триггеров в МС-Скуле, так сидел здесь на форуме и горько плакал, пока уважаемый Fay не подсказал один из вариантов решения проблемы. :)

← →
Sergey13 © (2005-05-26 09:41) [11]

Мне все таки непонятно, что обсуждаем? Безопасность или контроль доступа? Эти темы, хоть и перекликаются, но не совпадают. ИМХО.

2[7] Danilka © (25.05.05 17:10)
>Ну, например, какой-то юзер должен видеть только определенную группу клиентов в базе.
Это несложно решается и без вьюшно/процедурных наворотов.

Я тоже был одно время озабочен подобными вопросами. Потом подумав (я не работал со сведениями, составляющими какую либо тайну 8-), проанализировав реалии (ни один юзер на моей памяти не проникал в БД через Плюс или нечто подобное - 99.9% на это физически не способны 8-) я на это плюнул. 8-)

Что плохого, что юзер увидит "не своих" клиентов например? Если не увидит, то попытается его ввести - геморой. Что значит "своих"? А если юзер Иванов перешел работать в другое подразделение или ушел совсем? Передавать их всех Петрову? Удалять?

Читая про детальный контроль доступа и политики безопасности (когда к запросам автоматически дописываются условия) я обратил внимание, что примеры, там рассмотреные, обычно не сложнее select * from Table. У меня таких запросов практически нет. 8-) А если в действительно сложный запрос что то автоматически (во время выполнения) добавится, кто поручится, что производительность этого запроса не полетит вверх тормашками?

В общем, мне кажется, что прежде чем заниматься "безопасностью", надо шибко подумать - а оно надо?

← →
Danilka © (2005-05-26 10:00) [12]

[11] Sergey13 © (26.05.05 09:41)
Да не такие уж это и навороты. Просто, как ты сам сказал, простейших запросов select * from Table практически не бывает. В основном - сложные выборки из нескольких таблиц, а то и вьюх. Зачем все это писать на клиента, когда можно оформить вьюхой? А клиентов я привел просто как пример, хотя и такое тоже есть - есть задача, где у каждого менеджера есть четко закрепленные свои клиенты, их может быть штук десять - рыться в сотнях или тысячах контрагентах, где есть и поставщики и т.д., зачем? добавил группу: "клиенты такие-то", а у этого пользователя при подключении прописана эта группа как основная и вьюха клиентов, скоторой он работает чаще всего, фильтрует их по этой группы. У каждого менеджера - совя группа. Так им намного легче. :))

← →
ANB © (2005-05-26 10:05) [13]

> Sergey13 © (26.05.05 09:41) [11]

1. Обсуждаем контроль доступа. И безопасность тоже.
2. Я тоже не во все проекты ее вставляю
3. Но для коммерческих проектов класса ERP ее делать надо. Первый вариант уже видел. Начали подпрыгивать, когда продавцы залезли в базу девелопером и давай развлекаться. Ушло около миллиона баксов, а концов нашли далеко не на всю сумму. В результате юзеры сидели на компах с закрытым профилем, то есть могли запустить только ERP, не имели доступа к локальным дискам. Это и неудобно и все равно, при желании ломается. Доступ был заложен на грантах, то есть под этим же паролем юзер мог подключится к оракле напрямую. Я предложил идею с шифрованием пароля, но внедрить не успели - разогнали департамент.

← →
ANB © (2005-05-26 10:08) [14]

4. Тоже склоняюсь к 3-му варианту, тем более что в этом случае мутатинги не лезут (не уверен, вопрос к Danilka - лезут или нет ?).
Мутатинги штука вообще хитрая и могут вылезти не только в триггерах. В триггерах не очень сложный, но все равно гемморный способ обхода.

← →
Danilka © (2005-05-26 10:16) [15]

[14] ANB © (26.05.05 10:08)
А что такое "мутатинги"? :)
Да и нет никакого гемороя - зачастую триггер запускает процедуру из пакета, т.к. вьюх одного и того-же, например, документа может быть много, а процедура добавления/изменения одинаковая.
Кроме того, триггер выполняет какие-то необходимые действия, которые так или иначе все равно надо выполнить, так что геморой в любом случае одинаковый. :)

← →
Sergey13 © (2005-05-26 10:19) [16]

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

2[13] ANB © (26.05.05 10:05)
>Начали подпрыгивать, когда продавцы залезли в базу девелопером и давай развлекаться
Можно например повесить тригер на LogOn и анализировать имя проги.

← →
evvcom © (2005-05-26 10:22) [17]

> Ну, самое весомое отличие это то, что можно делать апдейт
> вьюхи по каким-то условиям, когда сразу апдейтятся несколько
> записей. С ХП это повторить уже сложнее.

Пример можно?

> И вообще, получается для клиента такая вьюха неотличима
> от таблицы

Точнее, наверное, не для клиента, а для разработчика. Хотя в данном случае это можно приравнять. Не буду спорить, есть кое-какие преимущества, но и есть недостатки. Ну куда же без них :). Во вьюху кроме единственного селекта больше ничего не запихаешь, а это тоже далеко не всегда удобно.

← →
Danilka © (2005-05-26 10:23) [18]

[16] Sergey13 © (26.05.05 10:19)
> Но целесообразность ее применения - это вопрос для каждого
> случая индивидуальный.

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

← →
Sergey13 © (2005-05-26 10:27) [19]

2[18] Danilka © (26.05.05 10:23)
> Для меня - практически решен. :)
Я не против. Решил и хорошо. 8-)

>т.к. зачастую, когда у клиента какая-то проблема, ее можно решить сразу на месте не имея дельфей и без перекомпиливания исходников, внося изменения только на сервере.
Это уже немного не по теме, согласись.

← →
Danilka © (2005-05-26 10:29) [20]

[17] evvcom © (26.05.05 10:22)
> Пример можно?

UPDATE v_my_data SET xxx = 1 WHERE yyy = 2
?
При этом, записей во вьюхе с yyy = 2 несколько десятков, например. А в случае, когда апдейт возможен только через ХП придется для каждой записи выполнять ХП.

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

не понял, что значит единственный селект? :) есть вьюхи с селектами из десятка таблиц, и тело вьюхе весом с десяток килобайт. :)

[19] Sergey13 © (26.05.05 10:27)
> Это уже немного не по теме, согласись.

Не по теме безопастности, но к теме вьюх - вполне подходит. :)

← →
evvcom © (2005-05-26 10:32) [21]

> Можно например повесить тригер на LogOn и анализировать
> имя проги.

А что, экзешник переименовать стало большой проблемой?

← →
Sergey13 © (2005-05-26 10:45) [22]

2 [21] evvcom © (26.05.05 10:32)
> А что, экзешник переименовать стало большой проблемой?
Нет. Это не проблема. Но до этого надо еще додуматься. Это раз. В тригере можно уведомить администратора. Это два. У тебя юзеры умеют дивелопером пользоваться (он у них вообще есть?!!!)? Умеют тригеры отключать? В БД нельзя вести логирование важной инфы в недоступных для прочих таблицах. Может к твоей базе проявляют интерес разведки врагов? Или наши компетентные органы? Это три, четыре и т.д.

Еще раз говорю. Я не против безопасности. Я за двумя руками!!! Но у нее много аспектов и методов повышения. Все три перечисленных в топике метода равноправны (ИМХО) и сильно зависят от качества реализации (что показано в [5]). Если такая проблема стоИт, то надо ей заниматься. Тратить на это время и деньги. Просто часто я вижу примеры легких параной с манией преследования, когда чуть ли не школьное расписание пытаются шифровать.

← →
evvcom © (2005-05-26 10:50) [23]

> А в случае, когда апдейт возможен только через ХП придется
> для каждой записи выполнять ХП.

Это почему? Что мешает в ХП такой же апдейт написать?

> есть вьюхи с селектами из десятка таблиц

Это понятно, что селекты во вьюхах тоже могут join-ы содержать. Только вот если тебе перед селектом надо бы десяток процедур выполнить, да хотя бы одну, то с вьюхой это уже не прокатит. И параметры. Вьюхой выдаешь жесткий набор строк или изгаляться через передачу параметров через запись в настроечные таблицы. А с ХП этих проблем нет.

← →
Val © (2005-05-26 10:51) [24]

>[15] Danilka © (26.05.05 10:16)
А что такое "мутатинги"? :)
мутатинги, насколько я помню из анекдота, возникают из-за немытого мутатора. :)

← →
evvcom © (2005-05-26 11:02) [25]

> Val © (26.05.05 10:51) [24]

Тебе надо в "потрепаться", т.к. "мутатинги" действительно в оракле существуют независимо от вымытости твоего мутатора.

← →
Sergey13 © (2005-05-26 11:06) [26]

2[25] evvcom © (26.05.05 11:02)
Нет. Когда не выполняют условия и ограничения (т.е. лезут с немытым мутатором 8-) и появляются мутатинги.

← →
Val © (2005-05-26 11:17) [27]

>[25] evvcom © (26.05.05 11:02)
да вы что? в оракле существуют мутатинги? а мне в потрепаться?
:) не смешите меня, уважаемый. _Мутации_ могут быть в любой серверной субд, при определенных действиях (например выборка в триггере из этой же изменяемой таблицы).
А мутатинги существуют в воображении вашем и не более. Или приведете литературный пример?

← →
ANB © (2005-05-26 11:33) [28]

> Val © (26.05.05 11:17) [27]
- Оракл есть ? Напиши триггер before rows for update, поселекай в нем свою табличку, а потом попробуй проапдейтить ее. Вылезет длинная ошибка. Ессно, это ошибка состоит не в мутации таблицы, а в кривых ручках прога и политике Оракл (т.к. в мсскуле такой ошибки не бывает), но ораклисты понимают проблему с полуслова и назыают ее "мутатинги". Исторически сложилось. Все имхо.

← →
ANB © (2005-05-26 11:35) [29]

> Но до этого надо еще додуматься.
- бывают очень прошаренные юзеры. Плюс, они и с прогами погут поделится. Безопасность же на админе висит. Ну поставили триггер на кассу. Так еще нашли кучу способов денежку уводить.

← →
Sergey13 © (2005-05-26 11:36) [30]

2[28] ANB © (26.05.05 11:33)
> Напиши триггер before rows for update, поселекай в нем свою табличку
Т.е. сделать как нельзя? И удивляться результату? 8-)

← →
ANB © (2005-05-26 11:37) [31]

Есть у меня еще мысля, по поводу трехслойки. Тогда юзер коннектится только к серверу приложения, а к оракле никакого доступа не имеет. Но ни разу не писал.

← →
Val © (2005-05-26 11:38) [32]

>[28] ANB © (26.05.05 11:33)
елки-палки..нет слов. вы, простите, сами понимаете, что пишите? или просто "мутатингов" боитесь?

← →
Sergey13 © (2005-05-26 11:39) [33]

2[29] ANB © (26.05.05 11:35)
>- бывают очень прошаренные юзеры. Плюс, они и с прогами погут поделится. Безопасность же на админе висит. Ну поставили триггер на кассу. Так еще нашли кучу способов денежку уводить.

Тогда вам надо в милицию обращаться. А если они (внутренние враги) еще и админа подкупят? А если и глава конторы в доле? Какую программу ты напишешь? Тут вызод один - топорм по серверу (или по сетевому кабелю как минимум) пока все не разворовали. 8-)

← →
Андрей Жук © (2005-05-26 11:49) [34]

Есть же триггеры уровня схемы, запрещай юзверям применять DDL. Снять такие триггера сможет только собственник схемы.

← →
Sergey13 © (2005-05-26 11:50) [35]

2[34] Андрей Жук © (26.05.05 11:49)
А где тут про DDL?

← →
evvcom © (2005-05-26 11:57) [36]

> Есть же триггеры уровня схемы, запрещай юзверям применять DDL

Зачем триггеры? Есть GRANT/REVOKE

> Val ©

Прицепился ты к слову. Не нравится "мутатинги" пиши "мутации", мне так вообще нравится оригинальное написание. Заметь, что этот сленг я писал в кавычках, как бы цитируя автора. С темой вижу знаком, но к слову прицепился, как ...

← →
ANB © (2005-05-26 11:59) [37]

> Т.е. сделать как нельзя? И удивляться результату? 8-)
- не, человек просил объяснить, что такое мутатинги. Я написал, как это посмотреть, вдруг не знает ?

← →
Val © (2005-05-26 12:02) [38]

>[36] evvcom © (26.05.05 11:57)
заметьте, смайл означает то что он означает. "прицепился" же я к вашей попытке послать меня в "потрепаться" после абсолютно безобидной шутки.

← →
ANB © (2005-05-26 12:06) [39]

Кстати, термин "мутации", как и "мутатинги" весьма условный. Просто на это слово начинается мессага об ошибке. Ну, думаю, ораклистам причину объяснять не надо.

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

← →
ANB © (2005-05-26 12:10) [40]

> Val © (26.05.05 12:02) [38]
- ну все остынь. Давай я перед тобой извинюсь. Ты по сабжу что нибудь имеешь ? А то уже Жук пришел, ща мы опять в холиварчик плавно переползем.

to Danilka - ты так и не ответил на вопрос - если я нагло буду нарушать правила (селекать из изменяемых таблиц например) в триггере instead of, мутатинг вылезет или нет ?

← →
Sergey13 © (2005-05-26 12:14) [41]

2[39] ANB © (26.05.05 12:06)
Я так думаю, что воруют в БД гораздо меньше чем просто так - несут то что плохо лежит. Если же
>Денежка вполне законно ушла
Тогда что ты этому противопоставишь? Вьюхи с процедурами?

Весь вопрос в соотношении потерь от слабой безопасности и затрат на сильную безопасность.

← →
ANB © (2005-05-26 12:17) [42]

> Sergey13 © (26.05.05 12:14) [41]
- все зависит от цены проекта. На тот проект в год тратилось $600000 (своя ERP). Ессно, за такие баки начальство хотело, чтобы все было круто. В том числе и безопасность.

← →
ANB © (2005-05-26 12:19) [43]

> Я так думаю, что воруют в БД гораздо меньше чем просто так
>
- там нести нечего было, стулья, столы и свой комп. А продавали дорогую технику. И при этом можно было аккуратно подкрутив базу, положить в карманчик за раз около $10000.

← →
Val © (2005-05-26 12:23) [44]

>[40] ANB © (26.05.05 12:10)
:) спасибо, не надо. я не нагревался.
По сабжу - сабж довольно расплывчат. Схема построения политики безопасности базы данных непосредственно зависит от содержимого базы, ее назначения, правил ее использования.
Вы предлагаете сравнить перечисленные варианты - они все хороши для одних конкретных случаев и плохи для иных. В чем тогда смысл обсуждения? Кто-то из этой ветки что-либо полезное вынес?

← →
ANB © (2005-05-26 12:31) [45]

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

> Кто-то из этой ветки что-либо полезное вынес?
- пока кроме Danilka никто ничего полезного и не постит.

А сабж спецально обобщенный, чисто теоретический. Хотелось бы знать, кто еще какими способами пользуется и при каких условиях.

← →
Sergey13 © (2005-05-26 12:31) [46]

2 ANB ©
Я уже говорил - безопасность это очень разноплановое понятие. Ну занимался ты пол года этим. Истратил 300000$. Нагородил изрядный частокол и распределил все права которые можно. Потом враги подошли к девочке операционистке и за шоколадку попросили рапечатать нужную инфу. А за золотое колечко изменить немного. И что? Может и не стоило столько вбухивать в это дело?
И это касается не только Оракла.

← →
ANB © (2005-05-26 12:42) [47]

> Потом враги подошли к девочке операционистке и за шоколадку
> попросили рапечатать нужную инфу

Ну во первых настройку грамотно построенной системы доступа можно свалить на заказчика.
Во вторых, если я (на месте заказчика) знаю, что программист закрыл все дыры, и, если я разрешил только этой девочке такую опасную операцию, то девочка мне долг вернет, продав квартиру. Да и вряд ли рискнет.

← →
Danilka © (2005-05-26 12:43) [48]

[28] ANB © (26.05.05 11:33)
Понятно. Я просто не знал как это называется. :)
Нет, конечно в триггерах instead of нет никаких мутатингов, оно и понятно почему: триггер заменяет стандартные действия.
Впрочем, можешь сам убедится:

create table test1 (xxx int primary key, yyy int)
/
create view v_test1 as select * from test1
/
create trigger tr_test1 instead of insert or update on v_test1 for each row
declare
v_xxx int;
begin
select nvl(max(xxx),0)+1 into v_xxx from test1;
delete from test1;
insert into test1 (xxx, yyy) values (v_xxx, :new.yyy);
end;
/
insert into v_test1 (yyy) values (12)
/
update v_test1 set yyy = 122
/
select * from v_test1
/

← →
Danilka © (2005-05-26 12:45) [49]

специально в триггере не добавил никаких условий, шоб страшнее выглядел :))

← →
Sergey13 © (2005-05-26 12:51) [50]

2 [47] ANB © (26.05.05 12:42)
> Во вторых, если я (на месте заказчика) знаю, что программист закрыл все дыры

Ты знаешь живые примеры такого? Нет, закзчиков, которые считают, что программист закрыл все дыры, я еще представляю. А вот программистов закрывших все дыры в сложных системах не видел. 8-)

ЗЫ: Основное воровство идет абсолютно легальными способами. Продал по заниженой цене, купил по завышеной. Откат в карман. А дивелопером в таблицах лазить - это извращение. 8-)

← →
ANB © (2005-05-26 12:53) [51]

Проверил. Действительно ничего не падает. Хотя эффекты прикольные при апдейте :))).
Получается, вариант 3 пока лучший. Не очень трудоемко, гибко и надежно.

Кто нибудь пробовал 4 ? Это сильно гемморно ?

← →
evvcom © (2005-05-26 12:56) [52]

> create view v_test1 as select * from test1

И все же, как ты поступаешь, если надо бы параметр какой в этот select добавить? Ну не надо мне лимон записей возвращать.

← →
ANB © (2005-05-26 12:56) [53]

> ЗЫ: Основное воровство идет абсолютно легальными способами.
> Продал по заниженой цене, купил по завышеной. Откат в карман.
- вот это ERP и закрывала. На любую подозрительную операцию продавец должен был запросить добро у руководства, и результаты ответа протоколировались. А девелопером можно было уже по факту цены подправить.

← →
ANB © (2005-05-26 13:00) [54]

> evvcom © (26.05.05 12:56) [52]
- ест два подхода
1. select * from v_test1 where bla-bla-bla
2. Стандартные запросы можно оформить разными вьюхами.
У нас сейчас по второму варианту безопасности система построена, то есть вьюхи и ХП. И хватает этого механизма.

← →
ANB © (2005-05-26 13:02) [55]

Хотя, согласен немного с evvcom ©, иногда добавляя условие к запросу из вьюхи можно сломать план и получить тормоза. Но это можно и без вьюх сотворить. А тестирование тогда зачем ?

← →
Danilka © (2005-05-26 13:04) [56]

[52] evvcom © (26.05.05 12:56)
Это просто пример. В реале, я и * никогда в секции перечисления полей не использую, и в самой вьюхе обязательно есть условия. А когда надо вытащить из вьюхи определенные записи - для них всегда есть секция where. Делаешь селект из вьюхи с какими-то условиями - никаких проблем. :)
Кроме того, в самих вьюхах в качестве условий могут выступать пакетные функции. А они, в свою очередь, могут юзать пакетные переменные. Которые могут менять пакетные процедуры. :))
Кстати, тоже бывает полезно, вовсе необязательно, но полезно, например, в клиентской программе есть рабочая дата. При изменении этой даты, меняется соответствующая пакетная переменная.
Есть куча вьюх на различные документы, все они показывают документы на рабочую дату, которую берут из пакета.
При этом, никаких дополнительных условий не надо ставить при селекте из вьюхи.

← →
Danilka © (2005-05-26 13:05) [57]

[55] ANB © (26.05.05 13:02)
Это да, бывает, нет в жизни щастья. :)
Приходится бороться, например, хинтами. Но это не такая уж и частая ситуация.

← →
evvcom © (2005-05-26 13:18) [58]

> в качестве условий могут выступать пакетные функции. А они,
> в свою очередь, могут юзать пакетные переменные

Вот про это я и спрашивал. Это аналогично моему "или изгаляться через передачу параметров через запись в настроечные таблицы" в [23]. Т.е. опять же что лучше применить View или Procedure зависит от конкретной задачи. Если мы решили, что фильтровать записи будем на сервере по нескольким параметрам, то делать копию всего этого списка в переменных пакета, мягко говоря, неудобно. Поэтому в этом случае я останавливаюсь все же на ХП. Mutating у меня встретился пока всего в одном месте, решение - два триггера и ассоциативный массив в пакете - не так уж и много, имхо.

← →
Polevi © (2005-05-26 13:24) [59]

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

← →
Sergey13 © (2005-05-26 13:29) [60]

2[59] Polevi © (26.05.05 13:24)
Это детальный контроль доступа. Есть такое.

← →
Polevi © (2005-05-26 13:38) [61]

>Sergey13 © (26.05.05 13:29) [60]
а зачем тогда
>Доступ только на вьюхи, изменения через instead of триггера
зачем прописывать правила в 2 местах если можно в одном ?

[58] evvcom © (26.05.05 13:18)
Понятно. Я как-то пропустил пост [23].
Кстати, обычно параметров не так уж и много, которые удобнее всего использовать в пакетных переменных, часть можно также использовать в таблице настройки параметров пользователя, которую точно также можно использовать во вьюхах.
Но, конечно, есть разные варианты. Ты остановился на ХП, я на вьюхах и оба довольны. :)

> Это детальный контроль доступа. Есть такое.

Насколько я понял о чем речь, то это только с 10 версии. А в основном народ пишет на 8 и 9.

> лучше применить View или Procedure
- ну, насколько я понял, вьюхи ты все равно юзаешь, только вместо триггеров instead of используешь ХП ? Или не так ?

2[61] Polevi © (26.05.05 13:38)
Это другой способ.

2[63] evvcom © (26.05.05 13:44)
>Насколько я понял о чем речь, то это только с 10 версии. А в основном народ пишет на 8 и 9.
Нет. Это появилось с 8и. Но сам я не пробовал.

> Это появилось с 8и.
- а поподробнее и с примером ? Это без прикола, есть есть детализированный доступ, то это круто. Что то я в доке на 9 не нашел ничего подобного, а гуру, который учил меня 8, грил что в оракле нету такого. В мсскуле я в доке видел такую штуку.

2[67] ANB © (26.05.05 14:09)

Я про это читал в ОраклМагазин давненько правда. Номера не помню.
http://www.oracle.com/global/ru/oramag/index.html

Это описано у Тома Кайта в его книге "Оракл для профессионалов". Глава, в том переводе что есть у меня, называется "Тщательный контроль доступа". Собственно эта глава и была в журнале.

Если есть желание могу выслать статью.

> вьюхи ты все равно юзаешь

не-а, не юзаю. Чтение MyProc#List, запись MyProc#Save

> Это детальный контроль доступа.
>
> Нет. Это появилось с 8и.

Тогда что это? Я подумал, что речь идет о разграничении полномочий на уровне строк, а это, насколько я знаю, только с 10-ки.

> Если есть желание могу выслать статью

Скинь мне на мыльце, если не в лом.

И мне ABelousov[sobaka]smartcard.ru

> evvcom © (26.05.05 14:21) [69]

Вот и нашелся пятый способ - процедуры, возвращающие НД.
А не тормозит ? Как легко сопровождается ? Как пишешь массовые апдейты/инсерты ?

> А не тормозит ?

Зачем? Какая разница: курсор он и в африке курсор!

> Как легко сопровождается ?

Открыл в редакторе так же как и вьюху и прочее, ну и сопровождай. Или ты о чем?

> Как пишешь массовые апдейты/инсерты ?

А я их не пишу. Юзер массово записи не правит, на каждую запись по ApplyUpdates вызов ХП. Но если надо, то проблем-то никаких. А как ты их массово хочешь менять, пример?

Ну например, накопали косяк в логике, а юзер уже месяц на поломанной проге сидел и хочет это все поправить. Обычно пишем update set = правильное значение where поломанные записи.

> Зачем? Какая разница: курсор он и в африке курсор!
- для сложных запросов из большого количества немаленьких таблиц сравнение делали ? Просто на вьюхах я уже влетал. Правда по глупости, надо было новую вьюху написать, а я готовую привязал.

2[71] ANB © (26.05.05 14:27)
>И мне ABelousov[sobaka]smartcard.ru

Вернулось с руганью. Может адрес не тот или у тебя с майл.ру не берет?

Млин, Belousov, я со старой работой перепутал. Плз, еще разок.

Ушло.

Заметил в книге уточнение. Это будет работать с 8.1.5 ЕЕ и выше.

Значит, для 9 по любому. Седня почитаю, я распечатал.
Листнул идею, - похоже на вариант evvcom ©, только ХП вызываются САМИ при любом обращении к таблице. Это даже удобнее, чем вьюхи.

> Ну например, накопали косяк в логике, а юзер уже месяц на
> поломанной проге сидел и хочет это все поправить. Обычно
> пишем update set = правильное значение where поломанные
> записи

Ну так это же не юзер, наверное, делает? Сам и пишешь такие разовые запросы, а в ХП их зачем пихать?

> для сложных запросов из большого количества немаленьких
> таблиц сравнение делали ?

все зависит от написанного селекта, а где он будет во вьюхе или хп, думаю, разницы совсем никакой. Хотя, конечно, иной раз оптимизатор такие финты выкидывает! А к готовой вьюхе/хп и из хранимки можно привязаться, но это уже не к теме.
Делал временные вьюхи, чтобы данные в Excel выдать, пока аналогичного модуля еще не написал, а нужно было срочно, потом модуль написал, а запрос перекинул в хранимку. По скорости разницы не заметил, но в удобстве использования вьюха далека от хранимки (наверное, лишь за исключением мутаций).

> Ушло.

Бегло пробежался по статье. Реализовано через стандартные пакеты dbms. Да, наверняка, это удобнее, чем писать такой контроль руками, но все равно тяжеловато. А в 10-ке такую весчь встроили уже в ядро. Но сам я не юзал, у меня 9.

2 [81] ANB © (26.05.05 15:31)
> Это даже удобнее, чем вьюхи
Вот это у меня и вызывает сомнения. Потому что "САМИ при любом обращении к таблице". Иногда надо иметь разные доступы к одной таблице. В одном случае только к "своим" (редактирование) в другом ко всем (аналитика какая нить), причем в одной сессии. Вот мне и показалось, что запаришься эти политики делать. А если в заросе таблиц с десяток, и на половину (или на все) стоят подобные ограничения. Вот и думай потом - почему запрос возвращает черти что или почему его производительность х.з. какая.

ЗЫ: В любом случае у меня стоял Standart Edition и мне это не пришлось попробовать. 8-)

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

> Sergey13 © (26.05.05 15:41) [83]
тоже верно. Полностью ручками написанный и оптимизнутый запрос, имхо, мне кажется надежнее, чем автоматическая каша.

Но, читай первые страницы - там становится понятно, почему защиту лучше делать на сервере.

2[84] ANB © (26.05.05 16:10)
>Но, читай первые страницы
Ты не поверишь - я читал. Попробовать не смог (посему и сомнения остались), но читал. 8-)

>Sergey13 ©

Привет, Сергей, если не трудно мне статейку тоже вышли. У тебя мой адрес был или адрес в анкете(был вроде :) )
Спасибо заранее.

Если кому интересно, работаю по третьему варианту - проблем не испытываю.

Как лучше построить безопасность БД ? (Oracle) Найти похожие ветки