Существует некая база, где каждому типу Объекта учета соответвует своя таблица. Некоторые из атрибутов этих об-в учета это так называемые (пользуюсь сложившейся у нас терминологии) - "Множественные поля типа справочник". Например - тип объекта учета - "Физич Лицо" - в нем есть поле "Гражданство". У физлица может быть несклько гражданств, Иванов Иван Иваныч может быть гражданином США и Израиля. "Гражданство" оформлено в виде отдельного справочника в отдельной таблице. Для хранения полей типа "Множественное поле типа справочник" для всех типов объектов учета используется отдельная таблица MultiValues с полями ID(просто аутоинкременный айдишник), IDDict (айдишник элемента справочника), IDObjType (айдишник типа обекта учета который связан с таблице в котором хранятся остальные данные этого типа объекта учета), IDObj - (айдишник самого объекта учета из таблицы) , IDField(айдишник атрибута этого типа Объекта учета ).
Но, здесь возникли два неприятных момента..
а)У нас для аудита изменений на каждую таблицу для типа объекта учета повешен триггер, который скидывает все изменения в некие отдельные таблицы которые хранят историю. Причем каждому изменения объекта учета соответсвует запись информации о событии - со своим айдишником. Чтобы учитывать изменения в полях типа "Множественное поле типа справочник", - пришлось на таблицу MultiValues тоже навешивать триггер. Но, получается что так как срабатывают два независимых триггера, то происходит запись двух и более событий, хотя это одно событие реально.
б) доступ к объектам учета реализован через набор вьюх, с разграничением по пермишшионам.
Отдельная таблица в эту схему вписывается, мягко говоря, криво.
////
ну и собственно вопрос - чо делать?
Пока на ум приходит только отказаться от отдельной таблицы MultiValues и писать эти множественные значения как некий строчный список через допустим запятую в основные таблицы объектов учета . Чем чревато такое изменение архитектуры, кроме того что здесь сложнее будет организовать поддержание ссылочной целостности через через Foreing Constrains - придется с триггерами мудрить..?

Роман Дынник Но, получается что так как срабатывают два независимых триггера, то происходит запись двух и более событий, хотя это одно событие реально.
Во многом зависит от СУБД...
в MSSQL, например, на
триггер срабатывает один раз. В нем нужно "раскрутить" таблицу inserted чтобы получить полный список.
Соответственно, применительно к MSSQL список можно передать как массив (например как текстовый параметр с xml) в хранимую процедуру, там получить из этого xml выборку (select f from OPENXML...), которую одним insert-ом и вставить.
Да, используется MSSQL 2005.

Роман Дынник Но, получается что так как срабатывают два независимых триггера, то происходит запись двух и более событий, хотя это одно событие реально.
Во многом зависит от СУБД...
в MSSQL, например, на
триггер срабатывает один раз. В нем нужно "раскрутить" таблицу inserted чтобы получить полный список.
Соответственно, применительно к MSSQL список можно передать как массив (например как текстовый параметр с xml) в хранимую процедуру, там получить из этого xml выборку (select f from OPENXML...), которую одним insert-ом и вставить.
Да, используется MSSQL 2005.
Прошу прощения - нажал на ctrl-enter случайно, недописав сообщение
Я не совсем понял вариант который вы предлагаете - список передать как массив откуда и куда? Или вы имеете в виду что писать эти множественные значения и туда и туда - чтобы не переделывать механизм доступа к этим множественным значениям,причем писать не в таблицу MultiValues не отдельной процедурой а тригером из основной таблицы ОУ?

что то я не с той ноги сегодня встал... :-)
в предыдущем посте фразу ",причем писать не в таблицу MultiValues не отдельной процедурой а тригером из основной таблицы " следует читать без "не" - ",причем писать в таблицу MultiValues не отдельной процедурой а тригером из основной таблицы"

а все таки, если хранить такие вещи как строковый перечень числовых айдишников через запятую, чем это чревато?

Роман Дынник McCarсписок передать как массив откуда и куда
с клиентского приложения в stored procedure.
проблема в том что мы тогда должны по хорошему передать в эту ХП айдишник события из таблицы Log_Fact куда собственно пишет триггер на таблицы ОУ ( таблица Log_Fact имеет структуру- ID, DateOfEvent, Login, ID_OT(айдишник типа объекта учета), ID_O(айдишник обхекта); сами изменненные значения пишутся из deleted в таблицу Log_depot которая связана с Log_Fact по этом айдишнику). А этот айдишник мы знаем только внутри триггера на основную таблицу.
Можно конечно вынести вообще всю запись истории на уровень бизнес логики приложения, но заказчик хочет чтобы даже при прямом доступе на сервер любые изменения были бы запротоколированы(случай когда хитрый юзер зашел под админом и отключил триггера не рассматриваем как и захват сервера вооруженной группой :-))

вообщем пока я вижу только такое решение - таблицу MultiValue закрываем для прямой записи, в таблицы объектов учета пишем список через запятую - который и записывается в историю по стандартной схеме, при этом триггер разбирает этот список и закидывает в таблицу MultiValues.
Кривовато и наверняка чем то чревато.. ну а как иначе?