[Devel] Информация для DBServer'а

[Pavel Vaynerman]

Вторник 14 сентября 2010, Ilya Shpigor написал:
> Единственное решение, которое вижу - это сделать специальный виджет,
И какой смысл, если этот виджет и есть журнал..?!
Вообщем см. ниже..
> который бы пересылал DBServer'у необходимую информацию обо всех
> сработавших датчиках и квитировании.
Вообще-то раньше механизм зенесения информации о квитировании был такой:

1. DBServer пишет в базу все изменения по датчикам (и знать не должен ни о 
каком квитировании.. т.к. это не его дело.)
2. При этом по этим же изменениям (SensorMessage) журнал формирует сообщения 
на экране (т.е. у него так же информация id,время и т.п.)
3. О квитировании знает только журнал, т.к. только в нём известно
какое именно сейчас сообщение требует квитирования 
(т.е. какое именно сейчас читает оператор).
Поэтому он посылал специальное сообщение ConfirmMessage DBServer-у,
в котором передавалась информация (id, время срабатывания, тип сообщения и 
т.п.), того датчика который квитируем..
По этой информации DBServer делал
UPDATE confirm_time='confirm.time'... WHERE id=confirm.id AND 
time=confirm.time AND time_msec=confirm.time_msec AND type=confirm.type
Это конечно "псевдокод" запроса, но смысл в том, что, что для внесения 
информации о квитировании (UPDATE) не обязательно знать id-записи.. Запись 
можно найти по другим полям.
--------

Так что мне не совсем понятно, почему вы хотите "утежялить" DBServer, чтобы он 
ещё и квитирование обрабатывал.. (а он должен быть "лёгким", чтобы не 
"захлебнуться" в обработке ВСЕХ изменений..). Т.е. максимально быстро 
обрабатывать сообщения, собственно по этому я и делал его очень простым,
разобрал SensorMеssage и сохранил в БД (никако логики)..

P.S. Ты всё-таки разговаривал с sin@? 
(мы всё это с ним уже обсуждали, и я ему эти аргументы приводил)..

----------- следующая часть -----------
Вложение в формате HTML было удалено...
URL: <http://lists.etersoft.ru/pipermail/devel/attachments/20100914/176c6228/attachment.html>