Получение событий из базы данных

Я не очень хорошо знаком с базами данных и тем, что они предлагают за пределами операций CRUD.

Мои исследования привели меня к триггерам. В принципе, похоже, что триггеры предлагают такую ​​функциональность:

(из Wikipedia)

Обычно три события запуска приводят к срабатыванию триггеров:

  • Событие INSERT (когда новая запись вставляется в базу данных).
  • Событие UPDATE (при изменении записи).
  • Событие DELETE (по мере удаления записи).

Мой вопрос: есть ли способ, которым я могу быть уведомлен на Java (желательно, включая данные, которые были изменены) базой данных, когда запись обновляется/удаляется/вставляется с помощью какой-либо семантики триггеров?

Какие могут быть альтернативные решения этой проблемы? Как я могу прослушивать события базы данных?

Основная причина, по которой я хочу сделать это, - это такой сценарий:

У меня есть 5 клиентских приложений в разных процессах/существующих на разных компьютерах. Все они имеют общую базу данных (Postgres в этом случае).

Предположим, что один клиент меняет запись в БД, в которой заинтересованы все 5 клиентов. Я пытаюсь подумать о способах "уведомлять" об изменениях клиентов (желательно с прикрепленными данными ) вместо них запрашивает данные на некотором интервале.

Ответы

Ответ 1

Используя Oracle, вы можете настроить триггер на таблицу, а затем триггер отправить сообщение JMS. Oracle имеет две разные реализации JMS. Затем вы можете выполнить процесс, который будет "прослушивать" сообщение с помощью драйвера JDBC. Я использовал этот метод для внесения изменений в мое приложение и опрос. Если вы используете базу данных Java (H2), у вас есть дополнительные параметры. В моем текущем приложении (SIEM) у меня есть триггеры в H2, которые публикуют события изменений с использованием JMX.

Ответ 2

Не смешивайте базу данных (которая содержит данные) и события на этих данных.

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

Триггеры - это последняя вещь, потому что вы работаете над реляционными элементами, а не "событиями" на данных. (Например, "обновление" может на самом деле отобразиться на событие "компания изменило юридическое имя" ). Если вы полагаетесь на db, вам придется сопоставлять вставки и обновления с событиями реальной жизни.... что вы уже знали!

Затем вы можете сложить другие вещи поверх этих уведомлений - например, обработки потока событий - для поиска событий, которые заинтересованы другими.

Джеймс

Ответ 4

Вызов внешних процессов из базы данных очень специфичен для поставщика.

Сверху моей головы:

  • SQLServer может вызывать программы CLR из триггеры,

  • postgresql может вызывать произвольные C функции загружаются динамически,

  • MySQL может вызывать произвольные функции C, но они должны быть скомпилированы,

  • Sybase может выполнять системные вызовы, если они установлены до этого.

Ответ 5

Проще всего сделать, чтобы триггеры insert/update/delete вносили запись в какую-либо таблицу журналов, и ваша программа java контролировала эту таблицу. Хорошие столбцы в таблице журналов будут такими, как EVENT_CODE, LOG_DATETIME и LOG_MSG.

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

Ответ 6

Я думаю, вы смешиваете две вещи. Они оба являются высокоинтенсивными поставщиками.

Первое, что я буду называть "триггерами". Я уверен, что есть хотя бы один поставщик БД, который считает, что триггеры отличаются от этого, но несут меня. Триггер - это часть кода на стороне сервера, которая может быть прикреплена к таблице. Например, вы можете запустить хранимую процедуру PSQL при каждом обновлении в таблице X. Некоторые базы данных позволяют записывать их на реальных языках программирования, другие - только в их варианте SQL. Триггеры обычно достаточно быстрые и масштабируемые.

Другой я буду называть "события". Это триггеры, которые запускаются в базе данных, которые позволяют вам определять обработчик событий в вашей клиентской программе. IE, в любое время, когда есть обновления базы данных клиентов, пожар updateClientsList в вашей программе. Например, использование python и firebird см. http://www.firebirdsql.org/devel/python/docs/3.3.0/beyond-python-db-api.html#database-event-notification

Я считаю, что предыдущее предложение использовать монитор - это эквивалентный способ реализации этого, используя некоторую другую базу данных. Может, оракул? Службы MSSQL Notification, упомянутые в другом ответе, также являются другой реализацией этого.

Я бы зашел так далеко, чтобы сказать, что вам лучше ДЕЙСТВИТЕЛЬНО знать, почему вы хотите, чтобы база данных уведомляла вашу клиентскую программу, иначе вы должны придерживаться триггеров на стороне сервера.

Ответ 7

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

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

Ответ 8

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

Еще одно решение (если вы используете SQL Server 2005) - использовать службы Notification Services, хотя эта технология, по-видимому, заменяется в SQL 2008 (мы еще не видели чистую замену, но Microsoft об этом публично говорила).

Ответ 10

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

Ответ 11

Если вы используете postgresql, у него есть возможность прослушать уведомления от клиента JDBC.

Ответ 12

Я бы предложил использовать столбец timestamp, последний раз обновленный, а также, возможно, пользователь, обновляющий запись, а затем пусть клиенты проведут проверку временной метки своей локальной записи по сравнению с сохраненной записью.

Добавленная сложность добавления функциональности callback/trigger просто не стоит, на мой взгляд, если она не поддерживается бэкэнд базы данных и используемой клиентской библиотеки, например, службы уведомлений, предлагаемые для SQL Server 2005, используемые вместе с ADO. NET.