Синхронизация в реальном времени данных базы данных через все клиенты
Если Вы не хотите использовать установщик, и Вы не хотите, чтобы пользователь выполнил какие-либо дополнительные шаги, чтобы позволить файлы CHM по сети, почему бы не отступить к WinHelp? Vista не включает WinHlp32.exe из поля, но это в свободном доступе как загрузка и для Vista и для Сервера 2008.
2 ответа
Firebird имеет функцию под названием EVENT , которую вы можете использовать для уведомления клиентов об изменениях в базе данных. Идея состоит в том, что при изменении данных в таблице триггер отправляет событие. Firebird заботится о том, чтобы уведомить всех клиентов, проявивших интерес к мероприятию, по имени. После получения уведомления каждый клиент отвечает за обновление своих данных, запрашивая базу данных.
Клиент не может получить информацию из события о новых или старых значениях. Это сделано намеренно, потому что нет способа решить эту проблему с помощью изоляции транзакции. Ваш клиент также не может регистрироваться на события с использованием подстановочных знаков. Таким образом, вы должны разработать свое межсерверное уведомление в широком смысле и позволить клиенту обновиться, чтобы увидеть, что именно изменилось.
См. http://www.firebirdsql.org/doc/whitepapers/events_paper. pdf
Вы не упоминаете, какую клиентскую платформу или язык вы используете, поэтому я не могу посоветовать конкретный API, который вы бы использовали. Я предлагаю вам Google, например, "firebird event java" или "firebird event php" или аналогичный, в зависимости от языка, который вы используете.
Поскольку вы говорите в комментарии, что используете WPF, вот ссылка на Пример кода некоторого кода приложения .NET, регистрирующегося для уведомления о событии:
http://www.firebirdsql.org/index.php?op=devel&sub=netprovider&id=examples#3
Повторите ваш комментарий: Да, Механизм событий Firebird ограничен в возможности передавать информацию. Это необходимо, потому что любая информация, которую он может нести, может быть отменена или отменена. Например, если триггер отправляет событие, но затем операция, вызвавшая триггер, нарушает ограничение, отмена операции, но не события. Так что события могут быть лишь своего рода «намеком» на то, что произошло что-то интересное. Другим клиентам необходимо обновить свои данные в это время, но им не говорят, что искать. По крайней мере, это лучше, чем опрос.
Итак, вы в основном описываете механизм публикации / подписки - очередь сообщений . Я не уверен, что использовал бы СУБД для реализации очереди сообщений. Это можно сделать, но вы, по сути, изобретаете велосипед.
Вот несколько хорошо известных продуктов для очередей сообщений:
- Microsoft MSMQ (похоже, является частью Windows Professional и Server edition)
- RabbitMQ (бесплатный открытый исходный код)
- Apache ActiveMQ (бесплатный открытый исходный код)
- IBM WebSphere MQ (вероятно, излишек в вашем случае)
Это означает, что, когда один клиент изменяет данные таким образом, о котором, возможно, должны знать другие, этот клиент также должен отправить сообщение на очередь сообщений. Когда клиенты-потребители видят интересующее их сообщение, они знают, что нужно обновить свою копию некоторых данных.
SQL Server 2005 и более поздние версии поддерживают истечение срока кэширования источника данных на основе уведомлений.