sql-server - studio - optimizar base de datos sql server 2008

¿Mejores prácticas para almacenar una versión de esquema de base de datos en SQL Server? (4)

Tengo una aplicación que se implementará en las PC de producción con SQL Server. Quiero poder almacenar y recuperar una versión del esquema en mi base de datos. Me interesan las mejores prácticas para poder lograr esto, con los siguientes objetivos principales:

Capaz de almacenar y recuperar fácilmente un número de versión de la base de datos.
Oculto o más difícil de encontrar y manipular por los clientes.
Se puede editar / cambiar cuando creamos una nueva versión.
La copia de seguridad de la base de datos o la eliminación de la base de datos mantiene el número de versión para análisis forense.

Me gustaría que hubiera una forma de almacenar una "versión" en los metadatos o no en una tabla normal, a la que se pudiera acceder / configurar a través de un procedimiento almacenado del sistema.

¿Alguna idea o mejores prácticas?

EDITAR: Una opción que encontré que puede ser prometedora es usar las Propiedades extendidas de SQL Server, para poner un valor de clave asignado a la base de datos con "Schema_Version" y el número de versión. No está cifrado (pero el valor podría estarlo), y no está oculto, pero al menos se elimina de la estructura de base de datos real que algunos de nuestros usuarios y personal de campo exploran (¡para mi frustración! :))

He implementado una solución que se basa en una tabla que rastrea la versión de esquema de cuatro segmentos (mayor, menor, compilación, revisión) con marcas de tiempo cuando cada versión comienza y termina su validez. Solo una fila tiene NULL para finalizar la marca de tiempo, y esa es la versión actual.

Además, hay un montón de procedimientos almacenados que admiten este sistema de control de versiones, y todas las alteraciones de la base de datos deben usar estos procedimientos para probar y actualizar la versión del esquema tan pronto como realicen algún cambio en el esquema de la base de datos (por ejemplo, agregue una tabla, suelte una columna). , etc.).

Tenga en cuenta que el historial completo de cambios se almacena en la tabla que rastrea las versiones de la base de datos. La solución es muy flexible cuando algo sale mal. Por ejemplo, si un cambio se rompe en medio de la ejecución, todos los cambios que haya realizado con éxito se recordarán en la tabla de la versión porque después de cada paso ha aumentado el número de revisión. Puede mejorar el modificador y ejecutarlo de nuevo, omitirá automáticamente los pasos completados con éxito y continuará desde el primer paso que no realizó la última vez.

Hay un truco más (opcional): he usado números de compilación impares para versiones intermedias e incluso números de compilación para versiones completas. De esa manera, tan pronto como comienza una alteración, primero cambia el número de compilación al siguiente valor impar y luego hace lo que quiere. Si en algún momento ve un número de compilación impar (tercer segmento en el número de versión), entonces está seguro de que alguna modificación no se completó. Una vez que el modificador completa su último paso, simplemente cambia la versión del esquema una vez más, esta vez al siguiente número de compilación par, solo para notificar a todos que se ha completado.

Puede ver el código fuente completo, el manual y los ejemplos en este artículo: Cómo mantener la versión del esquema de base de datos de SQL Server

Lo que hice en una empresa anterior fue almacenar la versión en una tabla con algunos campos (versión principal, versión secundaria, compilación y fecha aplicada), para poder tener un historial de las actualizaciones. Establecer los permisos adecuados en la mesa fue suficiente para evitar la manipulación.

Si realmente desea que también sea difícil de leer para los DBA, puede almacenar esos valores en la tabla como cadenas cifradas. De esta manera solo te gustaría ahora cómo decodificarlos.

Sinceramente, simplemente almacenamos el número de esquema en cada una de nuestras bases de datos. Tenemos una tabla en la base de datos que solo es utilizada por el equipo de Administración de configuración de software, que nos informa la versión actual para que podamos ver rápidamente en qué entornos se encuentra la versión. No me preocuparía por ponerlo en algún lugar fuera de la base de datos ya que eso solo complica las cosas.

Supongo que si realmente quiere estar seguro, siempre puede crear un procedimiento almacenado con el valor codificado en él. Luego puede cifrar el procedimiento almacenado para que no puedan verlo / manipularlo sin que usted lo sepa. Solo puedes actualizar el SP cuando cambies la versión para ellos. También podría ingresar al sistema y eliminar el código de procedimiento almacenado de las tablas del sistema después de compilarlo, pero realmente no lo haría. Solo lleva a problemas.

Soy el gerente de producto para SQL Source Control y SQL Compare en Red Gate. Tuvimos que resolver este mismo problema, ya que nuestra herramienta necesita saber en qué versión estaban las bases de datos para seleccionar los scripts de migración apropiados para construir el script de implementación completo.

Consideramos una tabla de versiones, que es la solución más desarrollada en casa. Sin embargo, de nuestra investigación aprendimos que los usuarios querían mantener el conjunto de objetos de la base de datos "sin contaminar", por lo que optamos por la propiedad extendida a nivel de base de datos. Agregamos esto a los scripts de la siguiente manera:

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

Cuando la base de datos se carga en la Comparación de SQL, realiza una comprobación para asegurarse de que la versión que afirma corresponde a la versión almacenada en el control de origen.

¡Espero que esto ayude!