servidor - ¿Cómo hago una versión de una base de datos de SQL Server?

nivel de compatibilidad sql server 2017

Question

Necesito poner versiones en una base de datos SQL Server 2005 y tenerlas accesibles desde una aplicación .NET. Lo que estaba pensando es usar Propiedades Extendidas en la Base de Datos con un nombre de ''versión'' y por supuesto el valor sería la versión de la base de datos. Puedo usar SQL para llegar a esto. Mi pregunta es, ¿suena esto como un buen plan o existe una forma mejor de agregar versiones a una base de datos de SQL Server?

Supongamos que no puedo usar una tabla para guardar los metadatos.

Answer 1

Hago esto:

Crea una tabla de esquema:

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)

Actualizar esquema:

INSERT INTO SchemaVersion(Major, Minor, Build, Revision, Applied, Comment)
VALUES (1, 9, 1, 0, getdate(), ''Add Table to track pay status'')

Obtener la versión del esquema de la base de datos:

SELECT TOP 1 Major, Minor, Build from SchemaVersion
ORDER BY Major DESC, Minor DESC, Build DESC, Revision DESC

Adaptado de lo que leí en Coding Horror

Answer 2

Si entiendo correctamente su pregunta (diferenciando entre las versiones internas de la base de datos, como los números de compilación de la aplicación), podría tener algún tipo de tabla SYSVERSION que contenga una sola fila de datos con esta información.

Más fácil de consultar.

También podría contener varias columnas de información útil o varias filas que representan diferentes momentos en que se actualizó la copia de la base de datos.

Actualización: Bueno, si no puede usar una tabla para guardar los metadatos, entonces, la información externa de algún tipo (un archivo INFO en el disco duro?) O las propiedades extendidas serían el camino a seguir.

Aunque todavía me gusta la idea de la tabla :) Siempre puedes usar la seguridad para que solo sea accesible a través de un proceso almacenado personalizado get_db_version o algo así.

Answer 3

Usamos las Propiedades Extendidas como lo describió y funciona muy bien.

Creo que tener una mesa es excesivo. Si deseo rastrear las diferencias en mis bases de datos, uso el control de fuente y guardo todos los scripts de generación de db en él.

También utilicé algunas herramientas de diagrama ER para ayudarme a hacer un seguimiento de los cambios en las versiones de bases de datos. Esto estaba fuera de la aplicación real, pero me permitió ver rápidamente lo que cambió.

Creo que fue CASEStudio, o algo así.

Answer 4

La mejor manera de hacerlo es tener 2 procedimientos: un encabezado para controlar lo que se está insertando y validaciones de un pie de página para insertar los datos si el lanzamiento es bueno o no. El cuerpo contendrá tus scripts.

Necesita una envoltura que encapsule su secuencia de comandos y registre toda la información: en la versión de lanzamiento, se ha aplicado el número de secuencia de comandos, applyby, applydate date, release outcome "failed or succeeded".

Answer 5

Estoy usando una tabla dedicada similar a la solución de Matt. Además de eso, los modificadores de bases de datos deben verificar la versión actual antes de aplicar cualquier cambio al esquema. Si la versión actual es más pequeña de lo esperado, la secuencia de comandos termina con un error fatal. Si la versión actual es más grande de lo esperado, el script omite el paso actual porque ese paso ya se ha realizado algunas veces en el pasado.

Aquí está la solución completa con ejemplos y convenciones para escribir scripts alter database: Cómo mantener la versión de SQL Server Database Schema