Хочу поинтересоваться вашим мнением по следующему вопросу. В базе есть сущности, сущности связаны между собой отношениями много-ко-многим следующим образом. Пусть A и B - сущности, тогда между ними определена связка (таблица) A_B_Role (
A_ID NOT NUL REFERENCES A (ID) ON DELETE ...,
B_ID NOT NUL REFERENCES B (ID) ON DELETE ...,
Role_ID NOT NULL REFERENCES Role (ID) ON DELETE.,
);
где Role - словарь ролей (типов отношений). Все замечательно. Допустим у нас есть 4 сувщности, тогда между ними возможно 10 различных бинарных связок. Для одной из сущностей (C) надо знать, в каких ролях она выступает по отношению к другим. Т.е. необходима сумма Role по всем 10 связкам. Запрос такой выпонять неэффективно, поэтому я в свое время создал и табличку C_Role (
C_ID NOT NULL REFERENCES C (ID),
Role_ID NOT NULL REFERENCES Role (ID),
Counter NOT NULL NUMBER
). Смысл тривиален - для каждой сущности C можно узнать сколько раз и в каких ролях она выступала. На все связки повешены тривиальный триггеры, вставляющие и удаляющие строки этой таблицы. Например вставляется
A_C_Role - идем в C_Role, смотрим есть ли там строка WHERE C_ID = &c_id AND Role_ID = &role_id. Если нет - вставляем, если есть - увеличиываем счетчик на еденицу. Подход тривиальный, но имеет БОЛЬШОЙ НЕДОСТАТОК - блокироки при UPDATE, из-за которых постоянно виснут транзакции. Если сталкивались с подобными задачами, расскажите, плз, какие еще есть решения. P.S. Собственно счетчик мне не интересен.
На выходе мне нужно только знать в каких ролях выступала сущность.

Просто вставлять и удалять связки не пользуя счетчик - не пойдет. Сейчас в таблице около 14000 записей, сумма всех счетчиков - около 90000. И это еще цветочки... Бегать потом пусть и с битмэп индексом по таблице с миллионами строк - не здорово.