Есть клиент-серверное приложение (.net, MsSQL, "толстый" клиент). Есть территориально удаленный заказчик, которому периодически передаются частичные обновления для БД (в виде скриптов SQL), сервера приложений и клиентов для него (сборки). Хотелось бы в любой момент времени знать, установил ли заказчик последние обновления (т.е. не отличается ли приложение от того, на котором работали тестировщики).
Если для сервера приложений это сделать легко (достаточно проверить версии сборок сервера и клиентов), то для БД -- крайне затруднительно. Эксперты предлагают всю критическую информацию из БД (схемы таблиц, тексты хранимых процедур, данные из вспомогательных таблицы) экспортировать в текстовый формат, а затем расчитывать хэш для него, но мне что-то очень не нравится этот подход -- достаточно изменить одну букву в комментарии в хранимке, и хэши не совпадут.
. Тут описан общий подход, который я использовал в разных проектах, подогнав под нужды конкретного проекта.
Применительно к Вашей проблеме суть во введении версии БД наряду с версией ПО. И хранение этой версии в самой БД, откуда ёё легко достать.
Здравствуйте, meowth, Вы писали:
M>Всем добрый день, есть следующая задача.
M>Есть клиент-серверное приложение (.net, MsSQL, "толстый" клиент). Есть территориально удаленный заказчик, которому периодически передаются частичные обновления для БД (в виде скриптов SQL), сервера приложений и клиентов для него (сборки). Хотелось бы в любой момент времени знать, установил ли заказчик последние обновления (т.е. не отличается ли приложение от того, на котором работали тестировщики).
M>Если для сервера приложений это сделать легко (достаточно проверить версии сборок сервера и клиентов), то для БД -- крайне затруднительно. Эксперты предлагают всю критическую информацию из БД (схемы таблиц, тексты хранимых процедур, данные из вспомогательных таблицы) экспортировать в текстовый формат, а затем расчитывать хэш для него, но мне что-то очень не нравится этот подход -- достаточно изменить одну букву в комментарии в хранимке, и хэши не совпадут.
M>Можно ли эту задачу решить по-другому?
M>Спасибо.
Если заказчик ничего сам в базе не правит, то для того чтобы проверить установил ли заказчик последние обновления достаточно завести таблицу версий обновлений и апдетить ее из скрипта, который накатывает обновления. Если задача — шире, то тут возможны другие вариант создать эталонную БД, котороя гарантированно правильная и написать программу сравнения метаданных (я когда-то такое писал, с парсером, который пропускал комментарии, пробелы и т.п. и сравнивал только значимые части)
Здравствуйте, KRA, Вы писали:
KRA>Здравствуйте, meowth, Вы писали:
M>>Можно ли эту задачу решить по-другому?
KRA>Тема обновлений БД и работы с версиями обсуждалась. Навскидку здесь
. KRA>Тут описан общий подход, который я использовал в разных проектах, подогнав под нужды конкретного проекта. KRA>Применительно к Вашей проблеме суть во введении версии БД наряду с версией ПО. И хранение этой версии в самой БД, откуда ёё легко достать.
Но за вариант спасибо, и за ссылку -- отдельное.
В том то и дело, что такой вариант (как в Ruby, например) не подойдет -- заказчик может "случайно" поправить данные или версию и все отвалилось. Хотелось "прошить" данные в БД, чтобы можно было точно сказать, что ее -- поменяли.
Здравствуйте, vladpol, Вы писали:
V>Если заказчик ничего сам в базе не правит, то для того чтобы проверить установил ли заказчик последние обновления достаточно завести таблицу версий обновлений и апдетить ее из скрипта, который накатывает обновления. Если задача — шире, то тут возможны другие вариант создать эталонную БД, котороя гарантированно правильная и написать программу сравнения метаданных (я когда-то такое писал, с парсером, который пропускал комментарии, пробелы и т.п. и сравнивал только значимые части)
К сожалению, именно заказчик (силами своих админов + СлужБез) накатывает обновления. Поэтому вариант с версией от их кривых рук не спасает
За идею с эталонной БД спасибо, в какой-то мере так и пользуемся, но в моей ситуации она неприменима.
Здравствуйте, meowth, Вы писали:
M> Хотелось бы в любой момент времени знать, установил ли заказчик последние обновления (т.е. не отличается ли приложение от того, на котором работали тестировщики).
Ну пусть каждое обновление ставит в скрытую таблицу базы (к которой нет доступа из GUI пользователя), свою метку типа GUID`а/номера версии/специально формируемой строки версии. Тогда по метке (последней по времени) можете определить версию БД и то, какие скрипты были накачены.
А если заказчик сам полезет менять что-то в "скрытых" таблицах — это его личные проблемы. Ведь никто не запрещает заказчику сделать DELETE FROM... + логи почистить + физически уничтожить БД? Так что ваша проблема скорее всего решается административным путем.
P.S. Покопавшись в реестре Windows ведь тоже можно систему в нерабочее состояние привести. Например в каком-то системном GUID`е буковку поменять.
