sql — получить уникальное хеш-значение для любого заданного ввода, используя переполнение стека
Мне нужно регулярно проверять множество (100.000) строк и проверять, совпадает ли их текущее состояние с последней сохраненной версией в другой базе данных. Есть ли способ получить какое-то уникальное значение для строки, чтобы соответствовать им, или мне придется вручную проверять строки столбец за столбцом?
Исходная база данных — это база данных SQL Server 2005, и в таблице нет механизма отметок времени для действия создания, обновления и / или удаления. Я посмотрел вокруг, чтобы проверить, есть ли доступная информация о строках, но единственная доступная вещь — это псевдостолбец %%lockres%% и информация о строке, но это не предоставляет информацию о дате и времени.
Я ограничен в своих инструментах, но у меня есть веб-сервер под управлением Apache и PHP и прямой доступ к исходным и целевым базам данных. У меня есть только разрешения на чтение исходной базы данных.
Что было бы наиболее эффективным способом для сравнения данных и поддержания производительности исходной базы данных.
Решение
Поскольку у вас нет доступа к базе данных, я предлагаю использовать «альтернативную» базу данных для хранения информации. Я могу придумать несколько разных подходов, каждый из которых имеет свои плюсы и минусы.
Подход 1
Поскольку использование хешей за пределами таблицы для проверок изменений потребует повторного запроса всех данных, что делает его очень медленной операцией, я бы использовал отдельную таблицу для хранения хешей, где вы всегда можете сначала проверить, соответствует ли значение, и только потом обнови это.
По сути, при вставке данных вы можете вычислить локальный хеш из этих данных, затем сравнить его с вспомогательной базой данных, и если они не совпадают, вы знаете, что данные не синхронизированы, и можете обновить данные до реальной базы данных и сохранить новый хэш в базу данных помощников.
Плюсы:
- Только необходимые обновления для реальной базы
Минусы:
- Медленнее, чем использование хеш-значения в базе данных
Подход 2
Обновляйте запись в реальной базе данных всегда. Это самое простое решение, и если вам не нужно обновлять тысячи записей одновременно а также удаленная база данных может справиться с дополнительной нагрузкой, влияние на производительность не должно быть таким значительным. Это просто простые операции обновления.
Плюсы:
- Просто и легко сделать
Минусы:
- Дополнительная загрузка в реальную базу данных
Подход 3
Просто получите разрешение на изменение удаленной базы данных. Если вы собираетесь поддерживать эту вещь в течение длительного времени, это может быть просто лучшим в будущем.
Плюсы:
- Это будет работать быстрее
Минусы:
- Вам необходимо получить разрешение на изменение таблицы.
Хотя я говорю «база данных», в простейшем случае это может быть простой текстовый файл, база данных SQLite или что-то еще, что позволит вам обрабатывать локальные операции.
Другие решения
Других решений пока нет …