¿Ustedes de seguir la pista de los procedimientos almacenados y esquema de base de datos en su sistema de control de origen de elección?

Cuando usted hace un cambio (agregar una tabla, la actualización de un procedimiento almacenado, ¿cómo conseguir que los cambios en el control de código fuente?

Utilizamos SQL Server en el trabajo, y he comenzado a utilizar darcs para el control de versiones, pero tengo curiosidad acerca de las estrategias generales, así como útiles herramientas.

Edición: Wow, gracias por todas las sugerencias grandes, chicos! Me gustaría poder seleccionar más de uno «Aceptado Respuesta»!

InformationsquelleAutor Dana | 2008-09-16

21 Comentarios

  1. 43

    Elegimos script de todo, y que incluye todos los procedimientos almacenados y los cambios de esquema. No hay herramientas de wysiwyg, y no de fantasía ‘sync’ programas son necesarios.

    Los cambios de esquema son fáciles, todo lo que necesitas hacer es crear y mantener un único archivo para esa versión, incluyendo todos los datos y el esquema de los cambios. Esto se convierte en su script de conversión de la versión de x a x+1. A continuación, puede ejecutar en contra de una copia de seguridad de producción y de integrarlo en su ‘diario de construir’ para comprobar que funciona sin errores. Nota: es importante no modificar o eliminar escrito ya esquema /carga de datos sql como puede acabar rompiendo cualquier sql escrito más tarde.

    -- change #1234
    ALTER TABLE asdf ADD COLUMN MyNewID INT
    GO
    
    -- change #5678
    ALTER TABLE asdf DROP COLUMN SomeOtherID
    GO

    Para procedimientos almacenados, se elegirá para un solo archivo por procedimiento almacenado, y se utiliza la gota/formulario de creación. Todos los procedimientos almacenados son recreados en la implementación. La desventaja es que si el cambio se realiza fuera de control de código fuente, el cambio se pierde. Al mismo tiempo, eso es cierto para cualquier código, pero su DBA a necesidad de ser conscientes de ello. Esta realidad impide que las personas fuera del equipo de desescombro con los procedimientos almacenados, ya que sus cambios se perderán en una actualización.

    El uso de Sql Server, la sintaxis se parece a esto:

    if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[usp_MyProc]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
    drop procedure [usp_MyProc]
    GO
    
    CREATE PROCEDURE [usp_MyProc]
    (
        @UserID INT
    )
    AS
    
    SET NOCOUNT ON
    
    -- stored procedure logic.
    
    SET NOCOUNT OFF
    
    GO  

    La única cosa que queda por hacer es escribir un programa que recopila todos los archivos y crea un nuevo archivo con el conjunto de actualizaciones (como una sola secuencia de comandos). Hacer esto por primera adición de los cambios en el esquema a continuación, recursing la estructura de directorios que incluyen todos los archivos de procedimiento almacenado.

    Como un revés a la creación de scripts de todo, vas a ser mucho mejor en la lectura y la escritura de SQL. Usted también puede hacer todo este proceso más elaborado, pero este es el formato básico de cómo de control de código fuente de todos sql sin necesidad de ningún software especial.

    anexo: Rick es correcto que usted va a perder los permisos en procedimientos almacenados con GOTA/CREAR, por lo que usted puede necesitar para escribir otro guión volver a habilitar los permisos específicos. Este permiso script sería la última para ejecutar. Nuestra experiencia encontrado más problemas con ALTERAR los versículos de la GOTA/CREAR semántica. YMMV

    • Hmmm. Yo no tenía intenciones de que sea spam. Disculpas si lo hizo. Y no, yo no lo apruebo su término. Yo sólo era dar a conocer de una mejor implementación de esta tecnología que creo que es relevante para su respuesta. Su primera frase implica que estas herramientas son casi una carga de alguna manera, lo cual está bien, pero eso fue hace casi dos años! He eliminado mi comentario como se encuentran objetable.
    • Yo no encuentro tu comentario desagradable. Yo simplemente no desea iniciar un comentario conversación no relacionada directamente con mi respuesta.
    • Hablando de hacer este proceso más elaborado – hemos creado un TFS elementos de trabajo y de servicio de apoyo a este proceso y añadido algunas pruebas automatizadas. Es en codeplex: enlace
    • Usted podría incluir los permisos de los objetos dentro de la creación de secuencias de comandos por ejemplo SUBVENCIONES [usuario] EJECUTAR EN [lo que sea] IR. Esto sería negar la necesidad de mantener separados los permisos de secuencias de comandos, como cada objeto se crea con permisos necesarios.
    • usted podría. Creo que el proceso actual es de un solo archivo de permisos por usuario de sql que nos encontramos más fácil de gestionar.
  2. 8

    crear un «proyecto de Base de datos» en Visual Studio para escribir y administrar el código sQL y mantener el proyecto bajo control de versiones, junto con el resto de su solución.

    • en Visual Studio 2008 de la Base de datos Edition
  3. 8

    La solución que se utiliza en mi último trabajo fue para el número de guiones, como los que se han añadido al control de código fuente:

    01.CreateUserTable.sql

    02.PopulateUserTable

    03.AlterUserTable.sql

    04.CreateOrderTable.sql

    La idea era que siempre supimos que el fin de ejecutar las secuencias de comandos, y podríamos evitar tener que gestionar la integridad de los datos que los problemas que podrían surgir si se trató de modificar la secuencia de comandos #1 (que sería presumible causa de los Insertos en el #2 a fallar).

    • No el sistema de archivos del nombre de pedidos obtener el orden equivocado una vez que llegue a 100 scripts?
  4. 5

    Una cosa a tener en cuenta en su caída/crear secuencias de comandos en SQL Server es que los permisos de nivel de objeto se perderán. Hemos cambiado nuestro estándar para el uso de ALTERAR secuencias de comandos en lugar de eso, lo que mantiene los permisos.

    Hay un par de advertencias, como el hecho de que el abandono de un objeto cae la dependencia de los registros utilizados por sp_depends, y crear el objeto sólo crea las dependencias para ese objeto. Así que si se te cae o crear una vista, sp_depends ya no saben de los objetos de referencia que ver.

    Moral de la historia, el uso de ALTERAR las secuencias de comandos.

  5. 5

    Estoy de acuerdo con (y upvote) Robert Paulson de la práctica. Eso es suponiendo que usted está en control de un equipo de desarrollo con la responsabilidad y la disciplina a que se adhieran a esta práctica.

    A la «fuerza» que en mis equipos, nuestras soluciones de mantener al menos un proyecto de base de datos de Visual Studio Team Edition para la Base de datos de Profesionales de la. Como con otros proyectos en la solución, el proyecto de base de datos se pone de control de versiones. Hace un natural proceso de desarrollo de romper todo lo que hay en la base de datos en la que se puede mantener en trozos, «disciplinar» a mi equipo a lo largo del camino.

    Por supuesto, al ser un proyecto de Visual Studio, no es donde cerca de perfecto. Hay muchas peculiaridades que se ejecutará en que puede frustrar o confundir. Se tarda un poco justo de la comprensión de cómo funciona el proyecto antes de llegar a cumplir sus tareas. Los ejemplos incluyen

    Pero para los equipos que no tienen una práctica de control de versiones de sus objetos de base de datos, este es un buen comienzo. Los otros famosos alternativa es, por supuesto, Puerta roja de la suite de productos de SQL Server, que la mayoría de las personas que los utilizan considerar superior a la de Microsoft que ofrece.

  6. 4

    Creo que debería escribir un script que configura automáticamente su base de datos, incluyendo procedimientos almacenados. Esta secuencia de comandos, debe colocarse en el control de código fuente.

  7. 3

    Par de diferentes perspectivas a partir de mi experiencia. En el Oracle mundo, todo lo que fue gestionado por «crear» secuencias de comandos DDL. Como ahockley se mencionó, una secuencia de comandos para cada objeto. Si el objeto que se necesita para cambiar su secuencia de comandos DDL se modifica. Hay un contenedor de script que invoca a todos los objetos de secuencias de comandos para que pueda implementar el actual DB construir a cualquier ambiente que se desee. Este es el núcleo principal de crear.

    Obviamente, en un live aplicación, cuando usted empuje de una nueva generación que requiere, por ejemplo, una nueva columna, no vas a caer de la mesa y crearla de nuevo. Vas a hacer un ALTER script y añadir la columna. Así que cada vez que este tipo de cambio debe suceder, siempre hay dos cosas que hacer: 1) escribir el alter DDL y 2) actualizar el núcleo crear DDL para reflejar el cambio. Tanto ir a la fuente de control, pero el único alterar la secuencia de comandos es más que una momentánea punto en el tiempo de cambiar, ya que sólo se utiliza para aplicar un delta.

    También se puede usar una herramienta como ERWin para actualizar el modelo de avance y de generar el DDL, pero la mayoría de los Administradores de bases de datos que yo conozco no confiar en una herramienta de modelado para la generación de la secuencia de comandos exactamente de la manera que ellos quieren. Usted podría también utilizar ERWin para aplicar ingeniería inversa a su núcleo de secuencia de comandos DDL en un modelo periódicamente, pero eso es un montón de esfuerzo para conseguir que se vea a la derecha (cada chorro de tiempo que lo hacen).

    En el mundo de Microsoft, se empleó una táctica similar, pero hemos utilizado la Puerta Roja del producto para ayudar a manejar las secuencias de comandos y deltas. Todavía poner las secuencias de comandos de control de código fuente. Sigue una secuencia de comandos por objeto (tabla, procedimiento almacenado, lo que sea). En el principio, algunos de los Administradores de bases de datos realmente preferidos utilizando el SQL Server interfaz gráfica de usuario para administrar los objetos en lugar de utilizar secuencias de comandos. Pero que hace muy difícil gestionar la empresa de forma consistente a medida que crecía.

    Si el DDL es en el control de código fuente, es trivial para el uso de cualquier herramienta de construcción (generalmente ant) para escribir una secuencia de comandos de implementación.

    • ¿Has tenido la oportunidad de probar Puerta Roja SQL de la Fuente de Control para gestionar sus cambios en el esquema? Si no, por favor, darle una oportunidad, como lo que estaría muy interesado en conocer tu opinión! La ventaja es que usted puede llevar en el uso de SSMS, si es que todavía sus Administradores de bases de datos de preferencia. red-gate.com/products/sql_source_control/index.htm
  8. 3

    Me he encontrado con que, por mucho, la más fácil, más rápida y más segura manera de hacer esto es simplemente morder la bala y el uso de SQL de Control de código Fuente de RedGate. Guión y almacenado en el repositorio en cuestión de minutos. Sólo deseo que RedGate gustaría ver el producto como una pérdida líder de modo que pudiera conseguir un uso más generalizado.

  9. 2

    Similar a la de Robert Paulson, arriba, nuestra organización mantiene la base de datos bajo control de código fuente. Sin embargo, nuestra diferencia es que tratamos de limitar el número de secuencias de comandos que tenemos.

    Para cualquier nuevo proyecto, no hay un procedimiento establecido. Tenemos un esquema de la secuencia de comandos de creación en la versión 1, un procedimiento almacenado script de creación y, posiblemente, una inicial de carga de datos de secuencia de comandos de creación. Todos los procedimientos se mantienen en una sola, hay que reconocer que archivo enorme. Si estamos usando la Biblioteca de Empresa, se incluye una copia de la secuencia de comandos de creación para el registro; si se trata de un ASP.NET proyecto con el ASP.NET marco de aplicación (autenticación, personalización, etc.), incluimos ese guión. (Hemos generado desde el sitio de Microsoft de herramientas, a continuación, ajustado hasta que se trabajó en un replicable de la moda a través de los diferentes sitios. No es divertido, pero una valiosa inversión de tiempo.)

    Utilizamos la magia CTRL+F para buscar el proc nos gusta. 🙂 (Nos encantaría que SQL Management Studio tenido código de navegación como VS no. Suspiro!)

    Para las posteriores versiones, normalmente tenemos upgradeSchema, upgradeProc y/o updateDate secuencias de comandos. Para las actualizaciones del esquema, podemos MODIFICAR tablas medida de lo posible, la creación de otros nuevos según sea necesario. Para proc actualizaciones, debemos SOLTAR y CREAR.

    Una arruga hace pop-up con este enfoque. Es fácil generar una base de datos, y es fácil conseguir uno nuevo a la velocidad de la actual versión de DB. Sin embargo, el cuidado tiene que ser tomado con DAL generación (que en la actualidad-por lo general-lo hacen con Subsónico), para asegurarse de que DB/esquema/proc cambios se sincronizan sin problemas con el código que se usa para acceder a ellos. Sin embargo, en nuestros construir caminos es un archivo de proceso por lotes que genera la Subsónico DAL, por lo que es nuestro SOP para obtener el DAL código, volver a ejecutar ese archivo por lotes, a continuación, compruebe todo de nuevo en cualquier momento el esquema y/o procedimientos de cambio. (Esto, por supuesto, desencadena una fuente de construir, actualizar compartido dependencias de la correspondiente Dll … )

  10. 2

    En las experiencias del pasado, he mantenido la base de datos de cambios de origen controlada de tal manera que para cada versión del producto de cualquier base de datos los cambios siempre fueron de secuencias de comandos y almacenados en la versión que estamos trabajando. El proceso de compilación en lugar automáticamente a la base de datos a la versión actual basado en una tabla de la base de datos que almacena la versión actual para cada uno de los «aplicación». Una costumbre .neto utilidad de la aplicación escribimos sería, a continuación, ejecutar y determinar la versión actual de la base de datos, y ejecutar secuencias de comandos nuevas en contra de ella en el orden de los números de prefijo de las secuencias de comandos. Tendríamos unidad de pruebas para asegurarse de que todo estaba bien.

    Nos gustaría almacenar las secuencias de comandos de control de código fuente de la siguiente manera (estructura de carpetas debajo de):

    Estoy un poco oxidado en las actuales convenciones de nomenclatura de las tablas y procedimientos almacenados tan desnudo con mi ejemplo…

    [root]

        [aplicación]

            [versión]

                [guión]

    \scripts

        MyApplication\

            1.2.1\

                001.MyTable.Crear.sql

                002.MyOtherTable.Crear.sql

                100.dbo.usp.MyTable.GetAllNewStuff.sql

    Con el uso de una tabla de Versiones que tome en cuenta la Aplicación y la Versión de la aplicación sería restaurar la producción semanal de copia de seguridad, y ejecutar todos los scripts necesarios en la base de datos ya que la versión actual. Mediante el uso de .red nos eran fácilmente capaces de paquete esta en una transacción, y si algo falló queremos deshacer, y enviar correos electrónicos, por lo que sabía que la liberación había malos guiones.

    Así, todos los desarrolladores asegúrese de mantener esta en control de código fuente para la publicación coordinada, asegurándose de que todos los scripts que nos va a ejecutar en contra de la base de datos se ejecuta correctamente.

    Esto es probablemente más de la información que estaban buscando, pero funcionó muy bien para nosotros, y dada la estructura es fácil llegar a todos los desarrolladores a bordo.

    Cuando llegó el día de la liberación de todo el equipo de operaciones de seguir las notas de la versión y recoger las secuencias de comandos de control de código fuente y ejecutar el paquete contra la base de datos con el .neto de la aplicación que utilizamos durante la noche el proceso de construcción de lo que automáticamente el paquete de las secuencias de comandos en las transacciones de modo que si algo falló, es automáticamente rodar hacia atrás y sin afectar a la base de datos fue hecha.

  11. 1

    Procedimientos almacenados obtener 1 archivo por sp con la norma si existe gota/crear instrucciones en la parte superior. Vistas y funciones también tienen sus propios archivos por lo que son más fáciles de versión y la reutilización.

    Esquema es que todos los 1 de secuencia de comandos para empezar, a continuación, vamos a hacer cambios de versión.

    Todo esto se almacena en un visual studio proyecto de base de datos conectado a TFS (@ trabajo o VisualSVN Server @ home para cosas personales) con una estructura de carpetas de la siguiente manera:

    – proyecto

    — funciones

    — esquema

    — procedimientos almacenados

    — vistas

  12. 1

    En mi empresa, tendemos a almacenar todos los elementos de base de datos en el control de código fuente como secuencias individuales como haría para archivos de código individuales. Cualquier actualización que se hizo primero en la base de datos y, a continuación, migrar en el repositorio de código fuente para una historia de los cambios se mantiene.

    Como segundo paso, todos los cambios de base de datos se migran a una integración de la base de datos. Esta integración de la base de datos representa exactamente lo que la base de datos de producción debe verse como posteriores a la implementación. También tenemos de control de calidad de la base de datos que representa el estado actual de la producción (o la última implementación). Una vez realizados los cambios en la Integración de la base de datos, se utiliza un esquema de la herramienta de comparación (Puerta Roja del SQL Diff para SQL Server) para generar un script que va a migrar todos los cambios de una base de datos a la otra.

    Hemos encontrado que esto es bastante eficaz, ya que genera una única secuencia de comandos que podemos integrar con nuestros instaladores fácilmente. El mayor problema que suelen tener es que los desarrolladores olvidar a migrar sus cambios en la integración.

  13. 0

    Script de todo (creación de objetos, etc) y almacenar las secuencias de comandos de control de código fuente. Cómo hacer los cambios llegar? Es parte de la práctica estándar de cómo se hacen las cosas. Necesidad de agregar una tabla? Escribir un script de la TABLA. Actualización de un procedimiento almacenado? Editar el script de procedimiento almacenado.

    Prefiero una secuencia de comandos por objeto.

  14. 0

    Para procs, escribir los procs con contenedores de secuencia de comandos en archivos planos, y aplicar los cambios de los archivos. Si se aplica correctamente, entonces usted puede comprobar en el archivo, y usted será capaz de reproducirlo a partir de ese archivo así.

    Para los cambios de esquema, puede que tenga que comprobar en los scripts de forma incremental a hacer los cambios que hemos hecho. Escribir la secuencia de comandos, aplicar y, a continuación, comprobar en. Usted puede construir un proceso, entonces, para aplicar automáticamente cada esquema de secuencia de comandos en serie.

  15. 0

    Mantenemos procedimientos almacenados en el control de código fuente. La manera en que nosotros (o por lo menos yo) de hacer es agregar una carpeta de mi proyecto, agregue un archivo para cada SP y manualmente copiar, pegar el código en ella. Así que cuando me cambio la SP, yo manualmente necesidad de cambiar el archivo de la fuente de control.

    Yo estaría interesado en saber si la gente puede hacer esto de forma automática.

  16. 0

    Recomiendo mantener el esquema y los procedimientos almacenados en el control de código fuente.

    Mantener procedimientos almacenados de versiones permite que se revierte cuando se determina a ser problemático.

    Esquema es una forma menos obvia respuesta dependiendo de lo que quieres decir. Es muy útil para mantener el SQL que define las tablas de control de código fuente, para duplicar los entornos (prod/dev/usuario, etc).

  17. 0

    Hemos estado utilizando un enfoque alternativo en mi proyecto actual – no tenemos la base de datos bajo control de código fuente, pero en su lugar han estado utilizando una base de datos de la herramienta de comparación de la secuencia de comandos de los cambios cuando lleguemos a cada versión.

    Ha estado trabajando muy bien hasta ahora.

  18. 0

    Almacenamos todo lo relacionado con una aplicación en nuestro SCM. La base de secuencias de comandos se almacenan generalmente en su propio proyecto, pero son tratados como cualquier otro código de… diseño, implementación, prueba, confirmar.

  19. 0

    Puedo ejecutar un trabajo de guión a una formal de la estructura de directorios.

    El siguiente es VS2005 código, proyecto de línea de comandos, se llama desde un archivo por lotes, que hace el trabajo. app.config claves al final del código.

    Se basa en otro código que encontré en línea. Ligeramente un dolor de configurar, pero funciona bien una vez que lo tienes funcionando.

    Imports Microsoft.VisualStudio.SourceSafe.Interop
    Imports System
    Imports System.Configuration
    Module Module1
    Dim sourcesafeDataBase As String, sourcesafeUserName As String, sourcesafePassword As String, sourcesafeProjectName As String, fileFolderName As String
    Sub Main()
    If My.Application.CommandLineArgs.Count > 0 Then
    GetSetup()
    For Each thisOption As String In My.Application.CommandLineArgs
    Select Case thisOption.ToUpper
    Case "CHECKIN"
    DoCheckIn()
    Case "CHECKOUT"
    DoCheckOut()
    Case Else
    DisplayUsage()
    End Select
    Next
    Else
    DisplayUsage()
    End If
    End Sub
    Sub DisplayUsage()
    Console.Write(System.Environment.NewLine + "Usage: SourceSafeUpdater option" + System.Environment.NewLine + _
    "CheckIn - Check in ( and adds any new ) files in the directory specified in .config" + System.Environment.NewLine + _
    "CheckOut - Check out all files in the directory specified in .config" + System.Environment.NewLine + System.Environment.NewLine)
    End Sub
    Sub AddNewItems()
    Dim db As New VSSDatabase
    db.Open(sourcesafeDataBase, sourcesafeUserName, sourcesafePassword)
    Dim Proj As VSSItem
    Dim Flags As Integer = VSSFlags.VSSFLAG_DELTAYES + VSSFlags.VSSFLAG_RECURSYES + VSSFlags.VSSFLAG_DELNO
    Try
    Proj = db.VSSItem(sourcesafeProjectName, False)
    Proj.Add(fileFolderName, "", Flags)
    Catch ex As Exception
    If Not ex.Message.ToString.ToLower.IndexOf("already exists") > 0 Then
    Console.Write(ex.Message)
    End If
    End Try
    Proj = Nothing
    db = Nothing
    End Sub
    Sub DoCheckIn()
    AddNewItems()
    Dim db As New VSSDatabase
    db.Open(sourcesafeDataBase, sourcesafeUserName, sourcesafePassword)
    Dim Proj As VSSItem
    Dim Flags As Integer = VSSFlags.VSSFLAG_DELTAYES + VSSFlags.VSSFLAG_UPDUPDATE + VSSFlags.VSSFLAG_FORCEDIRYES + VSSFlags.VSSFLAG_RECURSYES
    Proj = db.VSSItem(sourcesafeProjectName, False)
    Proj.Checkin("", fileFolderName, Flags)
    Dim File As String
    For Each File In My.Computer.FileSystem.GetFiles(fileFolderName)
    Try
    Proj.Add(fileFolderName + File)
    Catch ex As Exception
    If Not ex.Message.ToString.ToLower.IndexOf("access code") > 0 Then
    Console.Write(ex.Message)
    End If
    End Try
    Next
    Proj = Nothing
    db = Nothing
    End Sub
    Sub DoCheckOut()
    Dim db As New VSSDatabase
    db.Open(sourcesafeDataBase, sourcesafeUserName, sourcesafePassword)
    Dim Proj As VSSItem
    Dim Flags As Integer = VSSFlags.VSSFLAG_REPREPLACE + VSSFlags.VSSFLAG_RECURSYES
    Proj = db.VSSItem(sourcesafeProjectName, False)
    Proj.Checkout("", fileFolderName, Flags)
    Proj = Nothing
    db = Nothing
    End Sub
    Sub GetSetup()
    sourcesafeDataBase = ConfigurationManager.AppSettings("sourcesafeDataBase")
    sourcesafeUserName = ConfigurationManager.AppSettings("sourcesafeUserName")
    sourcesafePassword = ConfigurationManager.AppSettings("sourcesafePassword")
    sourcesafeProjectName = ConfigurationManager.AppSettings("sourcesafeProjectName")
    fileFolderName = ConfigurationManager.AppSettings("fileFolderName")
    End Sub
    End Module
    <add key="sourcesafeDataBase" value="C:\wherever\srcsafe.ini"/>
    <add key="sourcesafeUserName" value="vssautomateuserid"/>
    <add key="sourcesafePassword" value="pw"/>
    <add key="sourcesafeProjectName" value="$/where/you/want/it"/>
    <add key="fileFolderName" value="d:\yourdirstructure"/>
  20. -1

    Si usted está buscando una manera fácil, la solución ya preparada, nuestro Sql Historiador sistema utiliza un proceso en segundo plano que sincroniza automáticamente los cambios de la DDL para TFS o SVN, transparente a cualquier persona a hacer cambios en la base de datos. En mi experiencia, el gran problema es el mantenimiento del código en el control de código fuente, con lo que se ha modificado en el servidor-y eso es porque generalmente, usted tiene que confiar en la gente (a los desarrolladores, incluso!) para cambiar su flujo de trabajo y recuerde revisar sus cambios después de que ellos ya han hecho en el servidor. Poner la carga sobre una máquina que hace que la vida de todos más fácil.

Dejar respuesta

Please enter your comment!
Please enter your name here