Самый совместимый способ прослушивания изменений базы данных?

Question

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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