|
|
su.dbms.sql- SU.DBMS.SQL ------------------------------------------------------------------ From : Ruslan Bikmetov 2:5020/400 06 Mar 2001 10:03:05 To : All Subject : Re: безопасность превыше всего? -------------------------------------------------------------------------------- Vadim Rumyantsev пишет в сообщении <983825079@f301.n5030.z2.ftn> ... >> Ограничение прав пользователей на те или иные операции с объектами БД >> в общем случае не исключают возможность деструктивного измения данных. >Расшифруй, пожалуйста. Если ты о том, что облечённый соответствующими >правами пользователь может всё испортить -- так это как бы >подразумевается его уровнем >ответственности, необходимым для получения этих прав. Да, я именно об этом. Я хочу выяснить возможность создания механизма (кстати под UDB 5.2) при котором пользователю будет затруднительно либо невозможно деструктивно изменить большой объем данных, по неосторожности либо злому умыслу, либо это изменение будет занимать продолжительное время. Причем пользователь имеет привелегии на изменение, в соответствии с логикой работы системы. Предположим ситуацию, когда работник узнает о своем увольнении, либо о каких-то иных неприятностях решает в отместку удалить данные из какой либо таблицы. Мне на ум приходит пока только написание триггеров, подсчитывающих среднее количество измененний за сутки и блокирующих операции при преодалении этого порога. С другой стороны как скажется большое колличество триггеров на производительности системы? Либо как здесь мне подсказали, написать интерфейс для модификации данных через SP, в которых реализовать всю необходимую логику Чаще всего пользователи изменяют за раз небольшое количество записей от 1 до 10шт. Я думаю, будет верно создать SP для операций только над одной записью. А из прикладной программы вызывать ее столько раз, сколько нужно. При этом лишить пользователей прав на прямое изменение данных. Здесь опять же встает вопрос производительности. Static SQL использовать затруднительно по следующим причинам: Клиентская часть написана в основном на С++ билдере. Переписать ее на static SQL и переучить программистов не представляется реальным. Кроме того со старых времен осталась масса приложений на VA for ST корые переписать тоже крайне затруднительно все они используют dinamic SQL. -- Ruslan --- ifmail v.2.15dev5 * Origin: OAO Kirovelectrosviaz (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /su.dbms.sql/6638269c51bd.html, оценка из 5, голосов 10
|