2010-03-03 10 views
18

Nuestro equipo acaba de experimentar por primera vez la molestia de no tener control de versiones para nuestro DB. ¿Cómo podemos agregar procedimientos almacenados como mínimo al control de versiones? El sistema actual que estamos desarrollando depende principalmente de los SP.Cómo agregar procedimientos almacenados al control de versiones

+3

puesto similar: http://stackoverflow.com/questions/146543/what-is-the-best-way-to-version-control-my-sql-server-stored-procedures –

Respuesta

19

Antecedentes: desarrollo un sistema que tiene casi 2000 procedimientos almacenados.

Lo más importante que he encontrado es tratar la base de datos como una aplicación. Nunca abriría un EXE con un editor hexadecimal directamente y lo editaría. Lo mismo con una base de datos; El hecho de que pueda editar los procedimientos almacenados desde la base de datos no significa que deba hacerlo.

Tratar la copia del procedimiento almacenado en el control de código fuente como la versión actual. Es tu código fuente. Compruébelo, edítelo, pruébelo, instálelo y revíselo. La próxima vez que tenga que cambiarlo, siga el mismo procedimiento. Al igual que una aplicación requiere un proceso de compilación e implementación, también deben hacerlo los procedimientos almacenados.

El siguiente código es una buena plantilla de procedimiento almacenado para este proceso. Maneja ambos casos de una actualización (ALTER) o nueva instalación (CREATE).

IF EXISTS(SELECT name 
      FROM sysobjects 
      WHERE name = 'MyProc' AND type = 'P' AND uid = '1') 
    DROP PROCEDURE dbo.MyProc 
GO 

CREATE PROCEDURE dbo.MyProc 
AS 

GO 

Sin embargo siguiente ejemplo es mejor en situaciones donde el control de acceso a los procedimientos almacenados. El método DROP - CREATE pierde GRANT información.

IF NOT EXISTS(SELECT name 
      FROM sysobjects 
      WHERE name = 'MyProc' AND type = 'P' AND uid = '1') 
    CREATE PROCEDURE dbo.MyProc 
    AS 
    PRINT 'No Op' 
GO 

ALTER PROCEDURE dbo.MyProc 
AS 

GO 

Además, crear un proceso para construir la base de datos completamente desde el control de código fuente puede ayudar a mantener las cosas controladas.

Crea una nueva base de datos desde el control de código fuente. Use una herramienta como Red Gate SQL Compare para comparar las dos bases de datos e identificar las diferencias. Reconcilia las diferencias.

Una solución más económica es simplemente usar la funcionalidad "Script As" de SQL Management Studio y hacer una comparación de texto. Sin embargo, este método es realmente sensible al método exacto que usa SSMS para formatear el SQL extraído.

+0

Interesante, no he encontrado a Red Gate antes. Lo voy a ver. Es difícil tratar de mantener a todos bajo control, aunque – Jonn

+1

@Darryl - SQL Server no quiere la segunda muestra porque "CREAR PROCEDIMIENTO" debe ser la primera declaración en el lote. –

+0

Otra opción más económica es la PhpStorm de JetBrains (y posiblemente otras de su línea * Storm) que tiene una herramienta de comparación de bases de datos sorprendentemente buena incluida. También es un editor decente con autocompletar para varios sabores de SQL. – Aron

1

Acabamos de agregar la instrucción CREATE de control de código fuente en un archivo .sql, por ejemplo:

-- p_my_sp.sql 
CREATE PROCEDURE p_my_sp 
AS 
    -- Procedure 

Asegúrese de que sólo poner un SP por archivo, y que el nombre del archivo coincide exactamente con el nombre del procedimiento (se hace las cosas mucho más fáciles de encontrar el procedimiento en el control de código fuente)

Solo necesita ser disciplinado acerca de no aplicar un procedimiento almacenado a su base de datos que no proviene del control de origen.

Una alternativa sería guardar el SP como una declaración ALTER en su lugar - esto tiene la ventaja de facilitar la actualización de una base de datos existente, pero significa que debe hacer algunos ajustes para crear una nueva base de datos vacía.

3

Creo que es bueno tener cada procedimiento almacenado con guiones en un archivo .sql separado y luego solo comprometer esos archivos en el control de fuente. Cada vez que se modifica un sproc, actualice el script de creación; esto le proporciona el historial completo de la versión en un sproc por sproc.

Existen herramientas de control de origen de SQL Server que se conectan a SSMS, pero creo que solo están creando scripts para los objetos db y confirmando esos scripts. Red Gate parece ser debido a releasing such a tool este año, por ejemplo.

+2

Se guardan a veces, pero ha habido situaciones que indican que no todos los programadores lo recuerdan todo el tiempo. – Jonn

1

He estado trabajando en esta herramienta para exactamente ese propósito.

La manera de asegurarse de que nadie olvide verificar sus archivos .sql actualizados es haciendo que su servidor de compilación fuerce los entornos de ensayo y en vivo para que coincidan con el control de origen ;-) (que esta herramienta le ayudará).

5

Definitivamente recomiendo alguna herramienta de terceros que se integre en SSMS. Además de SQL Source Control mencionado anteriormente, también puedes probar SQL Version desde Apex.

Lo importante es hacer esto realmente fácil para los desarrolladores si desea que lo usen y la mejor manera es usar una herramienta que se integre en SSMS.

1

La segunda solución de @Darryl no funcionó como lo sugirió @Moe. Modifiqué la plantilla de @ Darryl y lo hice funcionar, y pensé que sería bueno compartirlo con todos.

IF NOT EXISTS(SELECT name FROM sysobjects 
       WHERE name = '<Stored Proc Name>' AND type = 'P' AND uid = '1') 
    EXEC sp_executesql N'CREATE PROCEDURE dbo.<Stored Proc Name> 
    AS 
    BEGIN 
     select ''Not Implemented'' 
    END 
    ' 
GO 

ALTER PROCEDURE dbo.<Stored Proc Name> 
AS 
BEGIN 
    --Stored Procedure Code 
End 

Esto es realmente bueno porque no pierdo mis permisos de procedimiento almacenado.

Cuestiones relacionadas