При EAV модели, данные от разных объектов хранятся в одной таблице.

Триггеры по определению не должны производить те же изменения на ту же таблицу, а это необходимо для организации логики.

Как вывернуться?
Есть какойто общий подход, чтобы избежать зацикливаний?

В Postgresql есть правила (rule), но в них нет переменных которые предоставляет триггер.

Используются хранимые процедуры, только кто их будет запускать если не триггер.

С представлением и триггером instead off на нем, понятно, спасибо за идею.

Petro123 мод Роман ДынникВобщем же случае рекомендации такие - не использовать триггеры ни в EAV модели, ни в "нормальной" реляционной, а использовать хранимые процедуры.
В принципе да - использовать триггеры только в крайнем случае.
+1
триггеры - прошлое тысячилетие
:) А что же делать? Событийный подход хотелось реализовать..
Апликейшн сервер делать?

А проблема в том, что надо хранить два типа сущьностей.
1. Объекты
2. Связи между объектами.
Первое хорошо решается моделью EAV. Второе тоже EAV или как угодно ибо важно быстродействие.
А проблема в том что каждая связь несет с собой действие (метод или если конкретно то соответствующую ХП). Активизировать эту ХП может только триггер!
Если триггеры прошлый век, то весь подход не верный?

Второй вариант, данные в объекты передавать посредством соответствующих ХП. И уже в самих ХП определять все последующие действия согласно связям между объектами.

Какие плюсы минусы у этих подходов?

мод
Алексей КлючниковА проблема в том что каждая связь несет с собой действие
Непонятно что, кто и куда несет.
хм. есть связи информационные, которые ничего никуда не несут, а используются только для работы третьесторонных функций.
А есть изменяющие связи, такие подразумевают наличие ХП при активизации связи.
такая связь активизируется при изменении данных одного из связываемых объектов.

мод Алексей Ключников
такая связь активизируется при изменении данных одного из связываемых объектов.
Ну вот вам и первичное событие - его и надо обрабатывать.
Угу, только вот в таблице 1000 объектов, на них наложено 2000 связей,
100 разных типов связей. Т.е. на измнение данных в одном из обьектов
отрабатывает тригер, запускающий ХП, которая выясняет все взаимосвязи этого обекта и запускает соответствующие ХП (что то типа коллектора получается). ХП в свою очередь производят уже следующую волну изменени в ту же таблицу.
Все это взято с потолка потому что не реализовано и не протестировано,
но уже видно что поддержка целостности (в смысле обеспечение отсутствия зацикливаний),
задача не тривиальная.
Или тривиальная? :)

007. Алексей Ключников100 разных типов связей.
Например?
1. переложить данное обекта 5 параметра 10 в обект 7 параметр 11
2. добавить данное обекта 5 параметра 10 к данному в обекте 7 параметр 11
3. если данное обекта 5 параметра 1 = 4, обнулить парметры 30,25,35 у объекта 6
4. объект 1 подключен к обекту 2 (как пример информационной связи)
И т.д.

Petro123что за мега система с 1000 объектов ООП в РСУБД?
А клиент - просто тупой браузер?

Да, просто тупой браузер.

Petro123ещё лучше если вы ЭТО назовёте бизне-логикой в виде методов объектов-классов.
Т.к. в РСУБД нет такого, то:
- написать на Net в MS SQL Server
- написать в сервере приложений.
- взять готовые маппинг-трансформаторы (тут проскакивало)

Это все не бизнес логика. и тут нет присутствия MS.
маппинг-трансформаторы вроде как происходит попытка изобрести свой
маппинг-трансформаторы, со своей спецификой.


Связь подразумевает ХП, или ХП подразумевает связь, от перемены мест слагаемых,
в данном случае, ничего не меняется. Ускользает только смысл отличия свяи от объекта,
получаются некие перекрывающие друг друга объекты.

Перекрывающие друг друга объекты -- звучит.. слабо предложить структуру под это?

Что то меня отнесло от темы..
так как с борьбой с зацикливанием в EAV с триггерами.