|
|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Victor Metelitsa 2:5020/400 06 Mar 2001 12:19:24 To : All Subject : Re: безопасность превыше всего? --------------------------------------------------------------------------------
Ruslan Bikmetov wrote:
[...]
> Мне на ум приходит пока только написание триггеров, подсчитывающих
> среднее количество измененний за сутки и блокирующих операции при
> преодалении этого порога. С другой стороны как скажется большое
> колличество триггеров на производительности системы?
>
> Либо как здесь мне подсказали, написать интерфейс для модификации
> данных через SP, в которых реализовать всю необходимую логику
> Чаще всего пользователи изменяют за раз небольшое
> количество записей от 1 до 10шт. Я думаю, будет верно создать SP
> для операций только над одной записью. А из прикладной программы
> вызывать ее столько раз, сколько нужно. При этом лишить пользователей
> прав на прямое изменение данных. Здесь опять же встает вопрос
> производительности.
>
> Static SQL использовать затруднительно по следующим причинам:
> Клиентская часть написана в основном на С++ билдере. Переписать
> ее на static SQL и переучить программистов не представляется
> реальным. Кроме того со старых времен осталась масса
> приложений на VA for ST корые переписать тоже крайне
> затруднительно все они используют dinamic SQL.
SP не подойдут хотя бы из-за наличия этих самых legacy applications.
Стало быть - только триггеры. Только не подсчетами пускай занимаются, а
журналы изменений ведут. Т.е. для любой таблицы X должна существовать
таблица BACKUP_X, имеющая все колонки X и еще парочку-троечку (тип
изменения, время изменения, кто произвел изменения и т.п.) и триггеры
AFTER UPDATE и AFTER DELETE. Тогда можно будет не только узнать, кто
сделал гадость, но и выборочно откатить какие-то операции. [Конечно,
подтормаживать будет, и места займет многоЮ но ничего бесплатного не
бывает].
Чтобы оно поменьше тормозило рабочий сервер, можно выделить отдельный
под это дело (пользоваться репликацией - она само по себе имеет подобный
журнал), только тогда реализация выборочного отката будет затруднена.
--- ifmail v.2.15dev5
* Origin: Rostelecom/Internet Centre (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/5364543fe575.html, оценка из 5, голосов 10
|