Уведомление юзеров об изменении данных
Модератор: kdv
Уведомление юзеров об изменении данных
Здравствуйте, давненько Вас не тревожил.
Вопрос следующий: хочу, что бы пользователи немедленно видели изменения в БД, сделанные другими пользователями. Для этого открываю книгу Хелен Борри (рекомендую всем) и нахожу прекрасное решение через использование Post_Event. Только одно неудобство - для этого нужно на каждую таблицу написать по три тригера, соотвественно для Insert, Delete, Update для того, что бы написать там одну строчечку Post_Event 'Имя_события'. Не то, что бы мне лень это делать, но как-то настораживает такое количество тригеров для решения такой задачки. Может есть более цивилизованный способ.
Вопрос следующий: хочу, что бы пользователи немедленно видели изменения в БД, сделанные другими пользователями. Для этого открываю книгу Хелен Борри (рекомендую всем) и нахожу прекрасное решение через использование Post_Event. Только одно неудобство - для этого нужно на каждую таблицу написать по три тригера, соотвественно для Insert, Delete, Update для того, что бы написать там одну строчечку Post_Event 'Имя_события'. Не то, что бы мне лень это делать, но как-то настораживает такое количество тригеров для решения такой задачки. Может есть более цивилизованный способ.
Программа автоматизации работы секретариата при проведении соревнований по спортивному ориентированию. С базой могут работать одновременно несколько человек, не более 10, я думаю. Несколько ноутбуков могут стоять на промежуточных контрольных пунктах в лесу и при прохождении там спортсменов фиксируются их промежуточные результаты.. И вся информация должна оперативно поступать к коментатору (или коментаторам), которые в свою очередь озвучивают её для публики. Плюс на финише регистрируются окончальные результаты спортсменов, которые тоже должны быть своевременно прокоментированы.. Вот, собственно, небольшой фрагмент из постановки задачи..
Уже легше. Таки вводителям данных ничего рефрешить и вообще показывать не надо, а читатели ничего не редактируют. Не уверен, что это вообще задача для СУБД (сдаёцца мне, что данные должны валиться в плоский файл, окном просмотра которого управляет либо таймер, либо сам комментатор теребит клаву периодицки, а по окончании оный файл уже загружается в СУБД для истории, со структуризацией данных), но если таки да, то два варианта:
1. Евенты просто извещают комментаторов, что новые данные ЕСТЬ. Какие - неважно. И комментатор сам решает - свернуть ли ему пространный рассказ о детских и юношеских годах какого-то выдающегося спортсмена и освежить своё видение или дотрындеть до конца а потом уже. Тогда да, писать триггера. И в 1.5 и выше можно универсальные на все события. И можно их сгенерировать по шаблону, а не насиловать клаву.
2. Вычитка по таймеру.
В обоих случаях рефрешить надо не фулл, у комментатора вообще не должно быть на рабочем месте постоянно открытого датааваре-датасета. Должно добиваться аппендами что-то кеширующее, само с базой не связанное. А для аппендов - по таймеру ли, по воле комментатора ли - должно осуществляться вычитывание только новых данных. Для чего завести табличку связи комментатор-событие, вычитывать из таблицы событий то, для чего not exists в этой табличке где юзер=я (можно реализовать через лефт джойн) и при вычитке туда такую запись вставлять. В частном случае одного комментатора было бы проще пользоваться признаком читано-нечитано в таблице событий, по которому налажен индекс. Но, поскольку в таблице событий по данному конкрентному соревнованию будут явно не миллионы записей, а комментаторов явно не тысячи, на боле-мене пристойном железе должно летать и с натуральными сканами в пределах одного соревнования.
1. Евенты просто извещают комментаторов, что новые данные ЕСТЬ. Какие - неважно. И комментатор сам решает - свернуть ли ему пространный рассказ о детских и юношеских годах какого-то выдающегося спортсмена и освежить своё видение или дотрындеть до конца а потом уже. Тогда да, писать триггера. И в 1.5 и выше можно универсальные на все события. И можно их сгенерировать по шаблону, а не насиловать клаву.
2. Вычитка по таймеру.
В обоих случаях рефрешить надо не фулл, у комментатора вообще не должно быть на рабочем месте постоянно открытого датааваре-датасета. Должно добиваться аппендами что-то кеширующее, само с базой не связанное. А для аппендов - по таймеру ли, по воле комментатора ли - должно осуществляться вычитывание только новых данных. Для чего завести табличку связи комментатор-событие, вычитывать из таблицы событий то, для чего not exists в этой табличке где юзер=я (можно реализовать через лефт джойн) и при вычитке туда такую запись вставлять. В частном случае одного комментатора было бы проще пользоваться признаком читано-нечитано в таблице событий, по которому налажен индекс. Но, поскольку в таблице событий по данному конкрентному соревнованию будут явно не миллионы записей, а комментаторов явно не тысячи, на боле-мене пристойном железе должно летать и с натуральными сканами в пределах одного соревнования.
именно для СУБД, дело в том, что "вводящие" вводят только нагрудный номер учасника и отсекают системное время финиша (или промежуточного КП), а всё остальное - имя, команда, время старта и т.д. берётся из базы, потом делается промежуточный расчет и текущее распределение мест, возможны ситуации, когда учасники снимаются за неправильную отметку на КП, а потом их опять восстанавливают, потому, что они были сняты по ошибке ну и т.д.Merlin писал(а):Не уверен, что это вообще задача для СУБД
По поводу остального, предыдущая версия проги была написана давно на Clipper Sammer-87, ясно, что там и мечтать о возможностях жар-птицы не приходилось, ну и сейчас, что называется дорвался, хотелось крутизны по-полной.. Однако хорошо, что не зная броду, хоть спросил у маститых..
Приблизительно такая модель и была реализована раньше, так и сделаю сейчас это для проведения вполне приемлемо..Евенты просто извещают комментаторов, что новые данные ЕСТЬ.
И в 1.5 и выше можно универсальные на все события. И можно их сгенерировать по шаблону, а не насиловать клаву.
Я по старинке пишу скрипты и выполняю их при помощи своей примочки, которая эксплуатирует IBEScript.. А как генерерировать по шаблону - это любопытно, проконсультируйте пожалуйста или ссылочку, где можно почитать
из чистого любопытсва, что такое датасет я для себя уяснил, а вот датааваре, - как трактовать сей термин..у комментатора вообще не должно быть на рабочем месте постоянно открытого датааваре-датасета..
дык в большинстве случаев он один и есть.. просто спортивное ориентирование не есть олимпийским видом спорта, а с финансированием и олимпийских-то у нас, сами понимаете, вот и приходится организаторам постоянно прибегать к помощи дяденьки-спонсора.., а этот дяденька частенько попадается вредненький, интересуется знать как тратятся его кровные и лучшим способом удовлетворить его любопытсво и польстить самолюбие - это выделить ему отдельный ноут на котором "всё видно", а ещё лучше отдельный ноут и его другу (а как же без друга, кто ж оценит-то..), вот, собственно, где собачка порылась..В частном случае одного комментатора было бы проще..
Пока больше 700 учасников в текущей финишной базе не регистрировалось.. И последний на сегодня вопрос: имеет-ли значение реальное количество записей в таблицах, если в каждый момент времени от сервера требоваться будет возвратить (или обработать) лишь какую-то часть этих строк (скажем 700) и вся структура базы реализована таким образом, что нужную информацию можно идентифицировать по первичному ключу. Дело в том, что помимо использования данных из базы в данный момент времени для определения победителей и призеров, ещё по итогам года считаются и рейтинги спортсменов (упрощенно это количесво набранных очков на специально запланированных вначале года так назывемых ранговых соревнованиях) для определения претендентов в сборную страны и др. Сейчас эта работа выполняется в полуручном режиме, с использованием Excel как я полагаю.. но это же КАТОРЖНЫЙ труд.. посему хотелось бы хранить в базе, скажем год, этого достаточно.. При подсчете навскидку в самой большей таблице будет до 50 тыс. записей.. Из Вашего опыта, господа эксперты, прикиньте сильные-ли ожидать тормоза в конце года на ноутбуке 1,7 МГц, 256 оперативки, 20 гиг на винте, win2000Prof (ломанный конечно) ну и FireBird 1.5.3. Конечно не вопрос сделать отдельную базу под эту задачу и туда сливать, но хотелось бы знать ваш прогноз, дабы определиться для решения других задач (зарплата, складской учет) достаточно-ли будет этой технологии.. Имеется ввиду сервер FireBird, этот замечательнейший софт, при всей своей бесплатности обладающий такими чудесными возможностями..Но, поскольку в таблице событий по данному конкрентному соревнованию будут явно не миллионы записей
IBExpert.или ссылочку, где можно почитать
при чем тут вообще это. с тормозами - это не к нам. Это к себе. Как напишешь, такие тормоза и будут.прикиньте сильные-ли ожидать тормоза в конце года
издеваемся? www.ibase.ru/devinfo/ibfbfeature.htm см. примеры систем.достаточно-ли будет этой технологии..
Ну как-как... Сочиняешь текст шаблона, делаешь аппликушку, в которой селектишь названия пользовательских таблиц в базе и в цикле по результатам этого запроса пхаешь имя в в шаблон и (если нужно знать в какой таблице изменения) имя евента, полученный текст пхаешь в IBSQL и выполняешь.KVas писал(а): А как генерерировать по шаблону - это любопытно, проконсультируйте пожалуйста или ссылочку, где можно почитать
KVas писал(а): вот датааваре, - как трактовать сей термин..
Ну как-как... Как data-aware... Мона даже набрать это заклинание в Дельфе, жмакнуть F1 и подивиться...
KVas писал(а): И последний на сегодня вопрос: имеет-ли значение реальное количество записей в таблицах, если в каждый момент времени от сервера требоваться будет возвратить (или обработать) лишь какую-то часть этих строк (скажем 700) и вся структура базы реализована таким образом, что нужную информацию можно идентифицировать по первичному ключу.
Практически не имеет. Если действительно по первичному ключу.
KVas писал(а): При подсчете навскидку в самой большей таблице будет до 50 тыс. записей..
То есть, вообще не будет Не, кривым запросом можно завесить сервер и на пустой базе