Реализация хэша записи базы данных для отслеживания того, изменилась запись или нет

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

Итак, например, вот пример таблицы:

клиенты

  • ID
  • имя
  • телефон
  • факс
  • баланс

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

кроме того, это должно выполняться на нескольких разных базах данных и платформах, поэтому триггеры или что-то подобное не являются опцией, если только они будут работать на MySQL, PostgreSQL, SQL Server и SQLLite.

поля изменяются сторонним приложением, которое я не могу изменить, поэтому я не могу просто добавить флаг и заставить стороннее приложение установить флаг TRUE всякий раз, когда оно изменяет соответствующее поле.

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

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

редактировать

некоторые разъяснения: оба мои приложения и другое обновление приложения и вставка в эти таблицы. Я can сделать мое приложение вычислить начальный хэш. Я не могу заставить другое приложение вычислить его.

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

ДОПОЛНИТЕЛЬНЫЙ ВОПРОС

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

6
database hash

2 ответов

Это сложно. Вам все равно придется сканировать таблицу (или сканирование индекса), так как вам нужно вычислить новый хэш и сравнить его со старым хэшем.

Если триггеры невозможны из-за кросс - платформенных проблем, вы можете заставить компонент database engine вычислить текущий хэш (т. е. сохраненный вычисляемый столбец-эффективно как триггер). Это также кросс-платформенная проблема, хотя! Затем, если вы индексируете текущий хэш и ваш хэш, это относительно легкий поиск.

можете ли вы, по крайней мере, использовать поле timestamp для уменьшения количества хэшей, которые вам нужно проверить?

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

2

Я бы стандартизировал, как ваше приложение проверяет разницу, а не как база данных реализует ее. Попробуйте что-то вроде использования представления с определенным столбцом, который означает изменение. Затем используйте правильные трюки, реализованные в каждой базе данных, чтобы сделать это представление реальностью. Код, который зависит от проверки этой разницы, будет таким же, используя тот же вид и столбец.

0