Как мне изменить версию базы данных SQL Server?
Мне нужно поместить версии в базу данных SQL Server 2005 и сделать их доступными из приложения .NET. Я думал об использовании расширенных свойств в базе данных с именем «версия», и, конечно же, значением будет версия базы данных. Затем я могу использовать SQL, чтобы добиться этого. Мой вопрос: звучит ли это как хороший план или есть лучший способ добавления версий в базу данных SQL Server?
Предположим, я не могу использовать таблицу для хранения метаданных.
Ответы 5
Если я правильно понимаю ваш вопрос (различие между версиями внутренней базы данных, например номерами сборки приложения), у вас может быть какая-то таблица SYSVERSION, которая содержит одну строку данных с этой информацией.
Легче запросить.
Может также содержать несколько столбцов с полезной информацией или несколько строк, представляющих разное время обновления копии базы данных.
Обновлять: Что ж, если вы не можете использовать таблицу для хранения метаданных, то подходящим вариантом будет либо какая-то внешняя информация (файл INFO на жестком диске?), Либо расширенные свойства.
Однако мне все еще нравится идея таблицы :) Вы всегда можете использовать безопасность, чтобы сделать ее доступной только через пользовательский хранимый процесс get_ db_version или что-то в этом роде.
Я ищу альтернативы этому методу из-за архитектурных политик и т. д.
Я делаю это:
Создайте таблицу схемы:
CREATE TABLE [dbo].[SchemaVersion](
[Major] [int] NOT NULL,
[Minor] [int] NOT NULL,
[Build] [int] NOT NULL,
[Revision] [int] NOT NULL,
[Applied] [datetime] NOT NULL,
[Comment] [text] NULL)
Схема обновления:
INSERT INTO SchemaVersion(Major, Minor, Build, Revision, Applied, Comment)
VALUES (1, 9, 1, 0, getdate(), 'Add Table to track pay status')
Получить версию схемы базы данных:
SELECT TOP 1 Major, Minor, Build from SchemaVersion
ORDER BY Major DESC, Minor DESC, Build DESC, Revision DESC
Адаптировано из того, что я читал на Кодирование ужасов
Это можно сделать еще на один шаг и хранить метаданные для схемы, такие как таблицы, поля, типы и т. д. Это, однако, начинает уступать место динамической системе, где часть данных программы является самой схемой. , часто встречается в медицинской промышленности.
Мы используем Расширенные свойства, как вы их описали, и они работают очень хорошо.
Я думаю, что наличие стола - это перебор. Если я хочу отслеживать различия в моих базах данных, я использую систему управления версиями и сохраняю в ней все сценарии генерации базы данных.
Я также использовал некоторые инструменты диаграмм ER, чтобы отслеживать изменения в версиях БД. Это было за пределами реального приложения, но позволило мне быстро увидеть, что изменилось.
Думаю, это CASEStudio или что-то в этом роде.
Это выглядит очень многообещающе. Не могли бы вы сослаться на какие-либо источники передового опыта?
Лучше всего иметь 2 процедуры: один заголовок для управления тем, что вставляется, и проверка нижнего колонтитула для вставки данных, если выпуск хорош или нет. Тело будет содержать ваши скрипты.
Вам нужна оболочка, которая будет инкапсулировать ваш скрипт и записывать всю информацию: текущий релиз, номер скрипта, примененный, дата применения, результат релиза «не удалось или успешно».
Я использую специальную таблицу, аналогичную решению Мэтта. В дополнение к этому, изменения базы данных должны проверять текущую версию, прежде чем вносить какие-либо изменения в схему. Если текущая версия меньше ожидаемой, сценарий завершается с фатальной ошибкой. Если текущая версия больше, чем ожидалось, то скрипт пропускает текущий шаг, потому что этот шаг уже выполнялся иногда в прошлом.
Вот полное решение с примерами и соглашениями по написанию сценариев изменения базы данных: Как поддерживать версию схемы базы данных SQL Server
Вы имеете в виду управление версиями схемы или содержащихся в ней данных?