Самый совместимый способ прослушивания изменений в базе данных? - PullRequest
1 голос
/ 16 апреля 2009

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

Как лучше всего определить, была ли база данных записана? Я знаю, что Oracle и MS-SQL могут использовать триггеры или что-то другое для связи с другими службами, но я надеялся, что найдется метод, который будет работать с большим количеством типов баз данных SQL (SQL lite, MySQL, PostGRES).

Ответы [ 3 ]

1 голос
/ 16 апреля 2009

В вашем вопросе отсутствуют подробности, необходимые для хорошего ответа, но я попробую. Триггеры хороши для таргетинга таблиц, но если вы заинтересованы в общесистемных записях, вам понадобится лучший метод, который проще поддерживать. Для общесистемных записей я бы исследовал методы, которые обнаруживают изменения в журнале транзакций. К сожалению, каждый поставщик реализует эту часть по-своему, поэтому один метод, который работает для всех поставщиков, маловероятен. То есть метод, который работает на сервере базы данных, маловероятен. Но могут быть более элегантные способы выхода за пределы сервера на уровне ОС. Например, если журнал транзакций представляет собой файл на диске, то простой сценарий, который обнаруживает изменения в файле, будет указывать, что в БД была записана.

Имейте в виду, что вы просили только обнаружить запись в БД. Если вам нужно узнать, какой тип записи был, тогда вам нужно войти в журнал транзакций, чтобы увидеть, что там есть. И это определенно будет зависеть от поставщика.

0 голосов
/ 16 апреля 2009

Если вы хотите быть независимым от базы данных, опрос может работать. Это не очень эффективно или элегантно. Это также работает, если вы прокляты использовать базу данных, которая не поддерживает триггеры. Обходной путь, который мы использовали в прошлом, заключается в использовании сценария, который рассчитан (скажем, через cron) для выполнения select MAX(primary_key_id) from saidTable. Я предполагаю, что ваш первичный ключ представляет собой последовательное целое число и проиндексирован.

А затем сравните это со значением, которое вы получили при последнем запуске сценария. Если они совпадают, скажите сценарию выйти или спать. Если нет, делай свое дело.

Существуют и другие проблемы с этим подходом (т. Е. Задержки, если сценарий занимает слишком много времени, проблемы параллелизма и т. Д.) И, конечно, производительность тоже может стать проблемой!

0 голосов
/ 16 апреля 2009

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

...