Еще вопрос по триггерам INSTEAD OF

Крылатый
Дата: 30.01.2009 11:05:59
Задача связана с тем, чтобы создать представление, с которым можно работать как с полноценной таблицей.
В представление вносятся все поля из одной таблицы Organisations, а также добавляется несколько расчетных полей. При изменении значения этих полей проводится обработка с использованием INSTEAD OF UPDATE (см. http://www.sql.ru/forum/actualthread.aspx?tid=634366&hl=%f2%f0%e8%e3%e3%e5%f0 ).

Вопрос связан с тем, как с наименьшими потерями заставить обновляться все поля из базовой таблицы? Я так понимаю, что если использован триггер INSTEAD OF UPDATE - он отменяет это автоматическое обновление?
Какой тогда должна быть логика триггера? Как добиться обновления с наименьшим кодом триггера.
В Organisation более 10 полей:
org_id, name, name_eng, info, INN, NDS_status....
iap
Дата: 30.01.2009 11:11:03
Крылатый,

придётся перечислять все поля в UPDATE
Крылатый
Я так понимаю, что если использован триггер INSTEAD OF UPDATE - он отменяет это автоматическое обновление?
не отменяет, а ЗАМЕНЯЕТ на то, что Вы напишите в триггере INSTEAD OF UPDATE.
Другими словами, надо написать UPDATE таблицы в этом триггере с перечислением всех полей, как я уже сказал.
Крылатый
В Organisation более 10 полей
Glory
Дата: 30.01.2009 11:12:33
Крылатый
а также добавляется несколько расчетных полей. При изменении значения этих полей проводится обработка .

И кто же додумался до такого подхода ?
Крылатый
Дата: 30.01.2009 11:53:01
Glory
Крылатый
а также добавляется несколько расчетных полей. При изменении значения этих полей проводится обработка .

И кто же додумался до такого подхода ?


А как бы Вы поступили в таком случае? Перенесли логику в клиента?

Поясню подробнее задачу. Проводится рассылка приглашений по предприятиям разными способами (E-mail,почта и тд). Количество возможных вариантов приглашений может изменяться (например, кого-то пригласят при личной встрече). Но базовая первая рассылка проводится массово. Оператор (разумеется, не владеющий SQL) должен быстро отметить группу предприятий, кому была сделана отправка. Самый простой способ поставить напротив предприятий соответсвующие галочки.
Логика триггера INSTEAD OF UPDATE вносит на галочку "E-mail" запись в таблицу Invintation (i.Org_id=o.Org_id, i.type = 2, i.date=GetDate()). При снятии галочки (оператор, например, по ошибке ее вставил) - запись удаляется.
От связанной таблицы отказаться нельзя, т.к. к примеру, в случае возврата при посыле на неверный адрес отправка проводится повторно (но таких случаев единицы на фоне общей рассылки)
Glory
Дата: 30.01.2009 11:54:58
Крылатый
Glory
Крылатый
а также добавляется несколько расчетных полей. При изменении значения этих полей проводится обработка .

И кто же додумался до такого подхода ?


А как бы Вы поступили в таком случае? Перенесли логику в клиента?

На какого клиента ?
Вычисляемые поля потому и называются вычисляемыми, что рассчитываются на основе других полей.
А не другие поля рассчитываются на их основе.
Крылатый
Дата: 30.01.2009 11:56:25
Glory,

Так как бы Вы подход применили при решении описанной задачи?
Как связать битовые поля в представлении с записями в связанной таблице?
Glory
Дата: 30.01.2009 11:58:42
Крылатый
Glory,

Так как бы Вы подход применили при решении описанной задачи?
Как связать битовые поля в представлении с записями в связанной таблице?

Не понимаю вас. Какой подход ? Обновляются только явные столбцы. Все вычисляемые столбцы и так вычислятся
Крылатый
Дата: 30.01.2009 12:01:39
Glory,

Проводится рассылка приглашений по предприятиям разными способами (E-mail,почта и тд). Количество возможных вариантов приглашений может изменяться (например, кого-то пригласят при личной встрече). Но базовая первая рассылка проводится массово. Оператор (разумеется, не владеющий SQL) должен быстро отметить группу предприятий, кому была сделана отправка. Самый простой способ поставить напротив предприятий соответсвующие галочки.
Логика триггера INSTEAD OF UPDATE вносит на галочку "E-mail" запись в таблицу Invintation (i.Org_id=o.Org_id, i.type = 2, i.date=GetDate()). При снятии галочки (оператор, например, по ошибке ее вставил) - запись удаляется.
От связанной таблицы отказаться нельзя, т.к. к примеру, в случае возврата при посыле на неверный адрес отправка проводится повторно (но таких случаев единицы на фоне общей рассылки)

Как бы Вы решили эту задачу?
Крылатый
Дата: 30.01.2009 12:03:54
Glory,

Т.е. Пользователь может ввести поле прямо в связанную таблицу Invitations. Например Org_id=3, type=2, date=21.12.08
В представлении должно отобразиться Email=true.

И наоборот. Пользователь снимает галочку е-мейл напротив предприятия Org_id=3. Запись в Invitations должна удалиться
Glory
Дата: 30.01.2009 12:04:28
Крылатый
Glory,

Проводится рассылка приглашений по предприятиям разными способами (E-mail,почта и тд). Количество возможных вариантов приглашений может изменяться (например, кого-то пригласят при личной встрече). Но базовая первая рассылка проводится массово. Оператор (разумеется, не владеющий SQL) должен быстро отметить группу предприятий, кому была сделана отправка. Самый простой способ поставить напротив предприятий соответсвующие галочки.
Логика триггера INSTEAD OF UPDATE вносит на галочку "E-mail" запись в таблицу Invintation (i.Org_id=o.Org_id, i.type = 2, i.date=GetDate()). При снятии галочки (оператор, например, по ошибке ее вставил) - запись удаляется.
От связанной таблицы отказаться нельзя, т.к. к примеру, в случае возврата при посыле на неверный адрес отправка проводится повторно (но таких случаев единицы на фоне общей рассылки)

Как бы Вы решили эту задачу?

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