Hemos estado utilizando Visual Studio Team System Database Edition recientemente, y tengo que decir que ha funcionado muy bien. Todos los procedimientos almacenados se almacenan como archivos y se controlan dentro y fuera del control de fuente, y tiene herramientas para generar scripts, etc.
Además, en el pasado hemos utilizado scripts almacenados como archivos de texto que están registrados y fuera del control de la fuente La regla era que tenía que verificar el archivo, luego editarlo, por ejemplo, Management Studio, y guardarlo, y volver a comprobarlo. En la parte superior de cada archivo de script de procedimiento almacenado se descartaría el proceso almacenado existente. y luego usa la instrucción CREATE para crear una nueva (pasa por el problema CREAR/ALTERAR). Luego teníamos una herramienta que ejecutaba todos los scripts en el orden correcto para construir una base de datos en blanco desde cero, y luego usamos el producto SQL Compare de RedGate para generar un script para actualizar nuestras bases de datos existentes. Admito que fue tedioso.
Casi al mismo tiempo trabajé en un sistema con otros 10 desarrolladores, e implementaron un riguroso procedimiento de gestión de cambio de base de datos. Había muchas, muchas aplicaciones que dependían de un conjunto de 2 o 3 bases de datos. Cada vez que un esquema de base de datos tuvo que cambiar (aquí solo estamos hablando de tablas, columnas y vistas), se creó un documento que explicaba el cambio, y luego había una matriz que enumeraba los cambios frente a qué aplicaciones creíamos que impactaría . Luego, el documento se circuló y tuvo que ser revisado por alguien responsable de cada aplicación, y tuvieron que buscar a través de su aplicación para saber dónde podría verse afectado, etc. Fue un procedimiento largo y arduo, pero funcionó. Sin embargo, los procesos almacenados simplemente se almacenaban como archivos de texto en el control de fuente.
En el pasado más lejano, con proyectos más pequeños que eran más como aplicaciones de escritorio con una base de datos como el almacén de datos, cada vez que la aplicación se inició, me:
- Comprobar para ver si existía la base de datos, y Si no, cree que
- Comprobar la existencia de todas las tablas, y si no, ellos crear
- Comprobar la existencia de todas las columnas, y si no, añadirlos
Cada vez que necesitaba cambie el esquema, solo agregaría más código al final del código de inicio para modificar el esquema según sea necesario, teniendo cuidado de migrar cualquier información existente. El beneficio de esto fue que solo podría desinstalar y reinstalar una nueva versión del software, y automáticamente actualizaría la base de datos existente a la última versión. La instalación, las actualizaciones y el mantenimiento fueron un sueño. Sin embargo, eso no funcionaría para sistemas más "empresariales".
Puede reducir algunos de estos problemas adoptando Entidades ADO.Net u otro Entity Framework similar, como Entity Spaces. Estas son capas de mapeo relacionales de objetos. Generan automáticamente clases para cada entidad (tabla) en su base de datos, incluidas las propiedades de cada columna, etc. Luego, le permiten extender esas clases con lógica personalizada. Si puede evitar tener su lógica de negocio en procedimientos almacenados y ponerlos en las clases de la Entidad, entonces el beneficio es que están fuertemente tipados. Por lo tanto, si cambia el nombre de una columna, o elimina una columna y regenera sus clases de entidad, entonces su IDE o compilador marcará automáticamente todos los lugares donde se rompe el código. Obviamente, todo el código de entidad está naturalmente en control de fuente con el resto de tu código fuente también.
Eso es un gran problema, le he pedido mucho tiempo, pero todavía no hay una buena respuesta, la única respuesta parece ser coordinarlo mediante procedimientos operativos. – tekBlues
Creamos http://tessik.com/sqlhistorian por esta misma razón: confiar en un desarrollador para actualizar su control de versiones contra lo que ya hicieron en el archivo db es un ejercicio inútil. Nuestro sistema registra automáticamente el cambio en el control de fuente una vez que el T-SQL llega al servidor, sin ninguna interacción adicional del usuario. –
Muchas empresas ** no permiten ** que los desarrolladores apliquen scripts directamente en la producción, por lo que creo que el mejor escenario es permitir que (un DBA) actualice ** desde los scripts a la base de datos ** y no al revés. Sin embargo, en el mundo real es posible que alguien no siga correctamente los procedimientos de cambio, por lo que ** lo mejor es permitir la comparación bidireccional. Pruebe esta herramienta gratuita: ** [http://servantt.com] (http://servantt.com/?so) - le permite realizar ingeniería inversa de sus objetos, guardar en scripts, comparar bases de datos con scripts, iniciar WinMerge para comparación, actualización de scripts o aplicar cambios a la base de datos. – drizin