Оповещение+mssql2000

← →
em240 © (2007-12-11 14:53) [0]

Хочу сделать оповешение об изменениях в базе через msmq.
т.е. если произошло изменение в таблице, то срабатывает триггер, который кидается сообщение в очередь msmq.
Ваши мнения....

← →
Sergey13 © (2007-12-11 14:56) [1]

> [0] em240 © (11.12.07 14:53)
> Ваши мнения....

Мое отрицательное. Не дело сервера навязывать услуги, его дело их предоставлять по запросу.

← →
Sergey13 © (2007-12-11 14:56) [2]

Забыл добавить " в 99% случаев"

← →
em240 © (2007-12-11 15:12) [3]

А как реализовать 100% механизм, который будет оповещать клиентов об изменениях в БД?

← →
Sergey13 © (2007-12-11 15:13) [4]

> [3] em240 © (11.12.07 15:12)
А зачем им знать про изменения в БД? Вот тебе интересно, что в двух кварталах от твоей работы освободилось место для парковки?

← →
em240 © (2007-12-11 15:24) [5]

Это основа приложения.

← →
Павел Калугин © (2007-12-11 15:26) [6]

> em240 © (11.12.07 15:24) [5]
> Это основа приложения.

это как?

← →
Sergey13 © (2007-12-11 15:26) [7]

> [5] em240 © (11.12.07 15:24)

Ну это тебе лучше знать, приложение то твое, никому неизвестное.

← →
em240 © (2007-12-11 15:28) [8]

Павел Калугин © (11.12.07 15:26) [6]

> em240 © (11.12.07 15:24) [5]
> Это основа приложения.

это как?

Это значит, если 1 человек внёс измнения в БД, то об этом должны знать все.

← →
sniknik © (2007-12-11 15:29) [9]

> Вот тебе интересно, что в двух кварталах от твоей работы освободилось место для парковки?
это спам, т.е., то что тебе не нужно но сообщения об этом приходят.

← →
Sergey13 © (2007-12-11 15:30) [10]

> [8] em240 © (11.12.07 15:28)

На соседней улице еще место под парковку освободилось. Не надо?

← →
sniknik © (2007-12-11 15:31) [11]

> то об этом должны знать все.
зачем?
почему не только те, что будут работать после с это записью и только в тот момент что будут?

← →
em240 © (2007-12-11 15:31) [12]

Тут суть в другом. Триггер создаёт COM-объект, это плохо?

← →
Sergey13 © (2007-12-11 15:31) [13]

> [9] sniknik © (11.12.07 15:29)

А кто должен решать, что ему что-то надо? ИМХО клиент. Вот пусть и запрашивает.

← →
sniknik © (2007-12-11 15:32) [14]

em240
тебе вообще спам на мыло приходит? ты ему радуешься?...

← →
Sergey13 © (2007-12-11 15:33) [15]

> [12] em240 © (11.12.07 15:31)
> это плохо?

Само по себе ничего плохо. Вот например волосы - хорошо, красиво. А вот те-же волосы в супе - стошнить может.

← →
em240 © (2007-12-11 15:33) [16]

Особенность в том, что клиент этого не должен делать?

← →
Skyle © (2007-12-11 15:36) [17]

Насколько я знаю есть парочка подходов: IB Events и обновление по таймеру. Но лично я не разу ещё не сталкивался с задачей, где это было бы необходимо.

← →
Sergey13 © (2007-12-11 15:37) [18]

> [16] em240 © (11.12.07 15:33)

Ты на КГБ работаешь? Или партизанишь?
Может ты за разрешением сюда обратился - так никто тебя тут не накажет за воплощение желаемого - делай чего хочешь.
Хочешь совета и обсуждения - выдавай нормальные исходные условия.

← →
em240 © (2007-12-11 15:37) [19]

Skyle © (11.12.07 15:36) [17]

Насколько я знаю есть парочка подходов: IB Events и обновление по таймеру. Но лично я не разу ещё не сталкивался с задачей, где это было бы необходимо.

У меня ADO.

← →
sniknik © (2007-12-11 15:40) [20]

> Особенность в том, что клиент этого не должен делать?
не клиент, сервер.

сервер предоставляет сервисы, клиент у него их запрашивает по необходимости, и в подавляющем большинстве случаев необходимости не возникает...
если же сервер начинает эти сервисы клиенту навязывать то ничем хорошим это не кончается (исключения не рассматриваем).

> У меня ADO.
хоть дедушкин валенок, не в компонентах/технологиях дело.

← →
Anatoly Podgoretsky © (2007-12-11 15:52) [21]

MS SQL Notification Services и флаг в руки, и хорошие ноги.

← →
Павел Калугин © (2007-12-11 16:02) [22]

я сталкивался с плохо спроектированными задачам где действительно нужны подобные извращения.
решений 3.
плохие
1. запрашивать изменения по таймеру
недостаток - клиент молотит данные а тут рефренш пошел.

2. рассылать сервером сообщения и обрабатывать клиентом
если поток данных большой то клиент только и будет что данные перечитывать.

приемлемое
3. не позволять клиенту держать открытыми списки с часто обновляемыми данными
то есть открыл посмотрел-ввел закрыл

← →
Павел Калугин © (2007-12-11 16:07) [23]

> Anatoly Podgoretsky © (11.12.07 15:52) [21]

Если не ошибаюсь, это с 2005-го появилось?

← →
sniknik © (2007-12-11 16:19) [24]

> Если не ошибаюсь, это с 2005-го появилось?
отдельно устанавливаемая служба для 2000-го. если в 2005-й в поставку включили то под давлением вот таких вот "проекторов баз".

Дамс. Тута у нас проект новый делали. И всю логику документооборота повесили на оповещения (ВоркФлоу обозвали и в рекламу загнали как охриненную фичу).
Пока отлаживались - вроде ниче было, хотя почти год писали.
Выехали к заказчику - 5 юзеров вошли, начали работать и сервер сдох.
Потом судорожно переделывали уже практически готовый проект на статусную модель документооборота (как в старом проекте и было).

Штатно да, но существуют отдельно устанавливаемые, включая даже на уровне СП

приемлемое
3. не позволять клиенту держать открытыми списки с часто обновляемыми данными
то есть открыл посмотрел-ввел закрыл
Особенность в том, что они должны их держать открытыми.

ANB © (11.12.07 16:34) [26]

Дамс. Тута у нас проект новый делали. И всю логику документооборота повесили на оповещения (ВоркФлоу обозвали и в рекламу загнали как охриненную фичу).
Пока отлаживались - вроде ниче было, хотя почти год писали.
Выехали к заказчику - 5 юзеров вошли, начали работать и сервер сдох.
Потом судорожно переделывали уже практически готовый проект на статусную модель документооборота (как в старом проекте и было).

На MSMQ?

> em240 © (11.12.07 16:59) [28]
> Особенность в том, что они должны их держать открытыми.

А вот это и есть ошибка проектирования

> На MSMQ?

На оракле. Там тоже есть встроенное оповещение. И сервак был нехилый - я стока не зарабатываю.

> ANB (12.12.2007 13:17:31) [31]

Но в состоянии поставить на колени.

> Но в состоянии поставить на колени.

Не, это не я придумал. Я тихонечко сопровождаю старый работающий проект. :)

← →
BoxTer (2007-12-17 08:15) [34]

Ничего хорошего в этом нет. Юзера через некоторое время плакать будут. Тем более, если обновление данных будет происходить часто...
Данные должны приходить по запросу!

только одну ситуацию можно представить: юзер втыкает в монитор и должен видеть, что некий объект перешел в состояние "занято". Т.е. не надо даже и пытаться его заюзать.
Для этого достаточно обновления по таймеру + проверка занятости при обращении к объекту, если состояние не успело освежиться

Оповещение+mssql2000 Найти похожие ветки