dbms_alert- бомба вещь.

Нет, он не завязыается. Это просто средство оповещения всех заинтересованных сторон. Процесс, сигналящий алерт не знает, слушает ли его кто. 

Единственно, следует с оглядкой использовать алерты в конкурентных процессах.  Там была какаята не очевидная замута - точно не припомню какая, но я на ней обжигался. Сигнялящие в один алерт процессы выстраивались в очередь. Кажись на коммите.



Это сообщение отредактировал(а) Zloxa - 7.12.2010, 20:35

Будет несогласованость по чтению: репликация штука не моментальная. Это неплохо делать для аналитики, но для боевого OLTP бессмысленно - тут только RAC.

Это сообщение отредактировал(а) ToshaCh - 8.12.2010, 10:06

Он должен иметь представление о структуре кешей в слое представления. Для моего примера, при изменении роли, сервер должен послать алерт для всех юзеров у которых есть эта роль, что надо обновить кеш юзер->пермишен.



Да с чего вы вообще это все взяли? Стендбай только как резервный, на случай выхода из строя мастера. Никакого чтения/записи из/в него, пока мастер работает. Нагрузку на базу снижать кешом между СУБД и сервером приложений.

Ну, мне тоже показалось что ты говорил о том, чтобы нагрузку на чтение по стендбаям размазать.
Я даже нахожу что в этой идее действительно чтото есть.
Но, действительно, не для OLTP. Там слишком велико отношения количества записей к количесвтву чтений.
А вот для витрины какогонить интернет - магазина, где согласованностью чтений и актуальностью  данных вполне можно пожертвовать - да.


задача не достаточно формализована, чтобы можно было давать оценки решениям 
Однако смена прав пользователя, мне думается, не должна происходить столь часто, чтоб действительно имело смысл заморачиваться снижением гранулярности сброса кэша. Сбрасывать весь кэш и баста.

Добавлено @ 17:58
В смысле я себе представляю кэширование как разделяемый поцессами приложения ассоциативный массив.
Возможно его можно реализовать еще какими то способами, и тогда, действительно его реализация может оказаться проблематичной.

Это сообщение отредактировал(а) Zloxa - 9.12.2010, 11:13

Вот и я так подумал.

Добавлено через 14 минут и 15 секунд


Я пробовал такое реализовать. Боевая база работает по OLTP, а физический стендбай открыт для чтения (плюшка у 11g) для построения адских отчётов. Главная проблема с которой я столкнулся это устаревшие данные: на OLTP они уже не нужны, а для аналитики необходимы. Соответственно возникают грабли с производительностью. Следовательно нужен более умный перенос данных и его, на мой взгляд, логичнее делать имено на уровне базы.

Пользуясь тем что "в интернете опять кто-то неправ" хочу поднять тему  

А как организовать unit и интеграционные тесты в СУБД?

Откуда дровишки?

Ты о чем?

Имелось ввиду: так кто же не прав в инете? Те ссылку.   

Вроде что-то такое слышал есть...

Средствами реализации тестового сценария.

А что вообще имеет смысл тестировать?

Zloxa срывает покровы.




Капитан, мы жаждем подробностей  

Мы тоже. 

Чувствую долго ждать придется.

Ну это же твой наборос.

Взялся бросать - не говори что не дюж.

Емнип в этой теме в качестве примера было упомянуто четыре примера прикладной логики. Проведение документа, валидация документа, валидация корректности номера банковской карты, кэширование запроса привелегий пользователя.

Не мог бы ты вкратце изложить потерянный профит от невозможности проведения автотестов при решении таких и подобных задач  

Это сообщение отредактировал(а) Zloxa - 29.7.2011, 14:41