Скачать: CL | DM;

Еще раз о триггере   Найти похожие ветки 

← →
MsGuns ©   (2003-02-24 21:12) [0]

Пару дней назад я уже задавал подобный вопрос, но сейчас нужны уже "подробности"

Есть БД, в которой определены несколько таблиц, довольно тесно взаимоувязанных логически. Как пример, схема:

Накладная -> Детал накладной -> Остатки по приходам -> остатки по складам интегрированно.
Накладная -> Данные о проплате (детал) <- Таблица проплат

Хочестся сделать логику максимально серверной. Т.е. с помощью цепочек триггеров. При изменении (удалении) одной записи детала, вся цепочка кажется мне достаточно "удобоваримой" и "влазит" в одну транзакцию. Но что делать, если меняется весь документ ? К примеру, удаляется (деактивируется) вся накладная целиком ? Тогда каждая из подобных цепочек триггеров должна срабатывать энное кол-во раз (по числу строк в документе) - а это уже, ИМХО, не есть хорошо. Как с точки зрения взаимоувязки (уровнями изоляции) между клиентами БД, так и неприглядности "дергания" сервера одиночными запросами. Здесь хороша была бы ХП с массовыми запросами. К сожалению, подобных ситуаций в имеющейся у меня литературе не нашел.
Прошу с точки зрения опыта РЕАЛЬНОЙ работы в области проектирования и сопровождения SQL-серверов (в частности, семейства IB ) высказать свои замечания и рекомендации.

С искренним уважением и надеждой.

---

← →
DarkGreen ©   (2003-02-25 05:11) [1]

А что тебе мешает при создании вторичных ключей указать ON UPDATE CASCADE, ON DELETE CASCADE?

---

← →
Alexandr ©   (2003-02-25 05:47) [2]

> Хочестся сделать логику максимально серверной. Т.е. с помощью
> цепочек триггеров.

похвально, но не стоит забывать про ХП.


> При изменении (удалении) одной записи
> детала, вся цепочка кажется мне достаточно "удобоваримой"
> и "влазит" в одну транзакцию.

да.

> Но что делать, если меняется
> весь документ ?
> К примеру, удаляется (деактивируется) вся
> накладная целиком ?

совершенно аналогично.

> Тогда каждая из подобных цепочек триггеров
> должна срабатывать энное кол-во раз (по числу строк в документе)
> - а это уже, ИМХО, не есть хорошо.

почему нехорошо? Нормально...

> Как с точки зрения взаимоувязки
> (уровнями изоляции) между клиентами БД,

никаких проблем.

> так и неприглядности
> "дергания" сервера одиночными запросами.

какими запросами?
Ну или повесь еще триггер на таблмцу накладных.
Вообщем, проблема непонятна...

> Здесь хороша была
> бы ХП с массовыми запросами.

ну так что мешает?

> К сожалению, подобных ситуаций
> в имеющейся у меня литературе не нашел.

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.46 MB
Время: 0.015 c