Рекомендации по хранению версии схемы базы данных в SQL Server?

У меня есть приложение, которое будет развернуто на производственных ПК с SQL Server. Я хочу иметь возможность хранить и извлекать версию схемы в моей базе данных. Я заинтересован в передовом опыте, чтобы достичь этого, со следующими основными целями:

Возможность хранить и легко извлекать номер версии базы данных.
Скрывается или сложнее находить и манипулировать клиентами.
Возможность редактирования/изменения при создании новой версии.
Резервное копирование БД или дебатирование БД держит версию # для судебной экспертизы.

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

Любые идеи или лучшие практики?

EDIT: Один из вариантов, который может показаться перспективным, заключается в использовании расширенных свойств SQL Server, чтобы присвоить значение ключа |, присвоенное БД, "Schema_Version" и номер версии. Он не зашифрован (но может быть значение) и не скрыт, но по крайней мере удаляется из фактической структуры БД, которую просматривают некоторые из наших пользователей и полевых сотрудников (к моему разочарованию!:))

Ответ 1

Я менеджер продуктов для SQL Source Control и SQL Compare в Red Gate. Нам пришлось решить эту же проблему, так как наш инструмент должен знать, в какой версии были базы данных, чтобы выбрать соответствующие сценарии миграции для создания полного развертывания script.

Мы рассмотрели таблицу версий, которая является наиболее часто разработанным домашним решением. Однако из нашего исследования мы узнали, что пользователи хотели сохранить набор объектов базы данных "незагрязненными", поэтому мы выбрали расширенное свойство уровня базы данных. Мы добавляем это к скриптам следующим образом:

IF EXISTS (SELECT 1 FROM fn_listextendedproperty(N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL))
  EXEC sp_dropextendedproperty N'SQLSourceControl Database Revision', NULL, NULL, NULL, NULL, NULL, NULL
EXEC sp_addextendedproperty N'SQLSourceControl Database Revision', @RG_SC_VERSION, NULL, NULL, NULL, NULL, NULL, NULL

Когда база данных загружается в SQL Compare, она выполняет проверку, чтобы убедиться, что версия, которая, по ее утверждению, соответствует версии, сохраненной в исходном элементе управления.

Надеюсь, это поможет!

Ответ 2

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

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

Ответ 3

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

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

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

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

Вы можете просмотреть весь исходный код, руководство и примеры в этой статье: Как поддерживать версию схемы базы данных SQL Server

Ответ 4

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

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