Запрет на удаление/изменение записи

← →
carmen (2004-06-05 11:39) [0]

Емется база даных. Каждая запись в любой таблице имеет поле PERIOD. Как запретить удаление/изменение записи, если значение поля PERIOD меньше активного периода. Нужен пример

Заранее благодарен

← →
Anatoly Podgoretsky © (2004-06-05 11:45) [1]

Не разрешать вообще удалять, а удалять хранимой процедурой

← →
carmen (2004-06-05 11:49) [2]

А через тригер както можно сделать

← →
Анатолий Подгорецкий © (2004-06-05 11:52) [3]

Тоже можно

← →
}{ander © (2004-06-05 12:12) [4]

> carmen (05.06.04 11:49) [2]
> А через тригер както можно сделать

Нужно

← →
carmen (2004-06-05 22:40) [5]

А как сделать через тригер

← →
Sergey Masloff (2004-06-05 22:49) [6]

>А как сделать через тригер
if new.period < current_period then
exception e_bad_period;

Но вообще см. Anatoly Podgoretsky © (05.06.04 11:45) [1]
так как есть мнение (и не только мое) что бизнес-логика в триггерах это не есть гуд. Все же лучше бы в ХП выносить - потому что и поддерживать проще и вообще...

← →
Sergey Masloff (2004-06-05 22:55) [7]

скобки забыл..
if (new.period < current_period) then
exception e_bad_period;

естественно exception надо объявить сначала

← →
Курдль (2004-06-06 00:47) [8]

> Но вообще см. Anatoly Podgoretsky © (05.06.04 11:45) [1]
>

Не засоряйте вы неокрепшие умы хранимыми процедурами! Я уже говорил, что чаще всего ХП - это роспись в собственном бессилии написать грамотный запрос. А в данном случае ХП не может быть гарантом целостности данных, в отличии от триггера. "Никогда не говори "никогда" в переводе на Программистский значит: "найдется такой ёлоб, который добавит запись в обход процедуры".

← →
Sergey Masloff (2004-06-06 02:18) [9]

Курдль (06.06.04 00:47) [8]
Это решаемо. Во-первых права на запись в обход процедуры можно отобрать (как это обычно и делается). И никаких проблем.
> Я уже говорил, что чаще всего ХП - это роспись в собственном >бессилии написать грамотный запрос
Ну, говорили вы явную чушь. ХП это прежде всего отличный способ обеспечения безопасности и управляемости системы, и очень удобный слой для размещения бизнес-логики. А бизнес логика в триггерах ИМХО допустима только в минимальных количествах - ну там проверить что дата не меньше текущей, что в фамилии нет цифр а возраст человека не более 150 лет... Кстати именно такого же мнения придерживаются и серьезные конторы занимающиеся независимым аудитом информационных систем - нам в силу специфики приходится эту процедуру (аудит) регулярно проходить. Вобщем, по этому вопросу мое мнение совпадает с аудиторами.
И при чем здесь неокрепшие умы? Учиться сразу нужно правильным технологиям.

← →
Курдль (2004-06-06 10:30) [10]

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

Представьте себе ситуацию. Жил да был приличный такой проект, над которым трудился немалый коллектив. Сдали, поделили бабло и забыли. Проходит пару лет и созревает клиент, готовый купить этот проект, но с условием, что тот будет работать на другой СУБД. Вроде все Ок. А посмотрели - мать моя! Вся логика на сервере и ХЗ уже, как работает. Да еще с надо с T-SQL перевести на PL/SQL!
"Лучшая рыба - это колбаса", а лучшая ХП - это ANSI запрос!

← →
Sergey Masloff (2004-06-06 11:54) [11]

Курдль (06.06.04 10:30) [10]
Да мифы это. Про перевод серьезного проекта содной платформы на другую. Такого НЕ БЫВАЕТ. Потому что для того и ивыбирается сервер чтобы МАКСИМАЛЬНО использовать его фичи под конкретную задачу. И те же ANSI запросы хинтовать придется совсем по-разному, да и работать все равно будет по-другому. А оставлять такую дыру как выполнение пользователем произвольных запросов... Ну уж нет.
Впрочем, случаи и проекты бывают разные так что ни мои ни ваши слова как абсолютную истину воспринимать не советую никому.

Про чушь вы (или ты - как удобнее) кстати извините - в пылу полемики ;-)

Система, вроде, многопользовательская, и логично, что активный период у каждого установлен свой. Значит ограничение и проверка должно быть еще на уровне интерфейса.

> Сергей Суровцев © (06.06.04 12:32) [12]
> Значит ограничение и проверка должно быть еще на уровне
> интерфейса.
Это первый ряд окопов :) А потом в SP.

> Курдль (06.06.04 10:30) [10]
> "Лучшая рыба - это колбаса",
Это точно
> а лучшая ХП - это ANSI запрос!
Как только дело выходит за рамки примеров из учебника по ANSI SQL, начинается либо использование всех возможностей SQL используемой СУБД, либо обработка на клиенте. Во втором случае приложение сразу теряет преимущества перед 1С, а о загубленном времени я говорить не буду.

> Вся логика на сервере и ХЗ уже, как работает.
Вот если "вся логика на сервере", небольшой шанс разобраться, как работает, еще есть, а вот если на клиенте - тогда точно ХЗ.

← →
Курдль (2004-06-06 20:27) [14]

> Да мифы это. Про перевод серьезного проекта содной платформы
> на другую. Такого НЕ БЫВАЕТ.

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

> А оставлять такую дыру как выполнение пользователем произвольных
> запросов... Ну уж нет.

А мож это не простой пользователь, а нач. отдела автоматизации, обиженный малым откатом? :)

В общем, - к теме использования ХП для реализации бизнес-логики.
Я двумя руками "за"! Но рекомендую сначала очень серьезно поискать другие варианты. Чаще всего многие проблемы с бизнес логикой возникают на этапе проектирования БД, а потом их пытаются исправить ХП и триггерами.

Запрет на удаление/изменение записи Найти похожие ветки