visual tools studio para microsoft intelligence data business visual-studio visual-studio-2008 database-design database-project

visual-studio - studio - visual database tools



¿Alguien que usa "proyectos de base de datos" en Visual Studio? (5)

Recientemente lo probé (versión SQL 2008) y los encuentro bastante bien. Bueno, el único problema es que el asistente no es lo suficientemente inteligente como para actualizar la estructura de la base de datos sin borrar primero todos los datos. ¿Es por esto que estos proyectos no se utilizan en la práctica?

En realidad nunca he visto a nadie usándolos o mencionándolos en absoluto. Tampoco hay nada que ver en los blogs y foros a menos que lo busques explícitamente.

¿Que hay de malo con ellos?


Al igual que Glennular, los estamos utilizando para controlar la versión de nuestros esquemas y s''procs.

Aunque tenemos una estructura de control de versión bastante avanzada (CI, implementaciones automáticas a dev, implementaciones de un solo clic para poner en escena y producir); No incluimos ninguno de los proyectos de DB en esa estructura. Simplemente no confiamos en eso todavía.

ACTUALIZACIÓN: (para Out In Space)

Tenemos proyectos TFS separados para áreas funcionales de la empresa (Ventas, Marketing, etc.). Dentro de cada proyecto TFS tenemos una carpeta principal y de producción. También tenemos un proyecto TFS que contiene los proyectos de la base de datos y otro que contiene ensamblados comunes / proyectos de estudio visual.

Tras el lanzamiento, nos ramificamos de Main a Production. No tenemos una sucursal en escena, ya que nos movemos demasiado rápido para lidiar con eso. Bien o mal, nuestra productividad se mide en parte por la cantidad de lanzamientos de niveles de producción que hacemos por semana; Corrección de errores, nuevas características, etc.

El CI se configura en la rama principal de modo que cada verificación hace que el servidor de compilación se implemente en nuestros entornos DEV. Las pruebas de unidades y web se ejecutan y la calidad de construcción se establece automáticamente en "Desarrollo" si se completa con éxito. Cuando alguien cambia la calidad de compilación a "En almacenamiento" Esto hace que cualquier compilación anterior "En almacenamiento" se establezca en "Rechazada" y hace que esa compilación se transfiera a nuestros servidores de almacenamiento al actualizar los archivos de configuración para que apunten a los servidores correctos. (Utilicé los scripts TFS Deployer y PowerShell para esto).

QA hace pruebas fuera de nuestros servidores de ensayo. Una vez que están contentos, el equipo de producción cambia la calidad de construcción a "Producción". Esto hace que la compilación se envíe a un área de producción que luego se copia manualmente a la ubicación correcta. Una vez completado, la producción notifica al desarrollo que luego ramifica esa versión en la carpeta Producción. También se notifica al QA quién hace una batería de pruebas de producción para verificar que todo funciona como se espera.

Tenemos informes configurados para mostrarnos qué cambios existen entre las versiones de producción para que sepamos cada verificación que se está implementando. Eso evita que surjan incógnitas, como un cambio en la base de datos, etc. o algún otro código que pueda romperse.

Además, nuestros licenciados están realizando un seguimiento de los elementos de trabajo a través de Team System Web Access y saben cuándo esos elementos están en producción.

Aunque nuestros DBA están utilizando Database Edition (GDR), no se han impresionado con el nivel de control de las implementaciones automáticas. Espero que Rosario aporte un mejor control de despliegue a la línea de productos; pero hasta entonces tenemos TFS Deployer y powershell.


Los he usado en algunos proyectos pagos y creo que es una gran herramienta. Eso dicho, he visto algunos problemas.

  1. Si el archivo .dat en su carpeta de proyecto de db no está sincronizado con la instancia temporal de la base de datos, la comparación de esquemas dará resultados inexactos. Si no está seguro de cómo sucede esto, revise cuidadosamente el esquema y elimine su archivo .dat (después de cerrar la solución) si las cosas parecen estar mal.

  2. Si tienes más de 20 bases de datos y se hacen referencia entre ellas y usan referencias circulares ... Va a doler. No he descubierto cómo escalar a ese escenario. GDR 2 parece ofrecer alguna promesa.


Nosotros los usamos. Mantenemos todos nuestros esquemas de creación / actualización de guiones y procedimientos almacenados. El propósito principal es que podemos conectar el proyecto a un SourceSafe o SVN.

Es una manera fácil de mantener su versión de scripts SQL controlada.

Es un poco peculiar tratar de hacer algunas pruebas de SQL en VS, pero encontrará formas de evitarlo.

Actualizar

De hecho, lo tenemos integrado en nuestros scripts de implementación, nuestra herramienta de implementación, pasa por el proyecto DB (excepto las carpetas marcadas) y ejecuta todo el script. Acabamos de construir una herramienta rápida para ejecutar el proyecto. Si alguien tiene otras soluciones para implementar el proyecto de base de datos que sería útil.


Usamos el proyecto de base de datos para proporcionar control de versiones para nuestros scripts SQL. También nos gusta usar el entorno de Visual Studio para editar el SQL; es un poco más fácil de usar para algunos de nuestros desarrolladores más nuevos que el analizador de consultas.


Uso el proyecto de base de datos que forma parte de Visual Studio Database Edition. Esta es una gran herramienta Básicamente, se define el esquema completo, en la creación de scripts que luego se verifican en el control de origen. Luego tiene herramientas integradas para generar scripts de diferencia, que por cierto no eliminan los datos.

También tiene herramientas de comparación de datos para que pueda comparar datos entre bases de datos y genere el script para hacer que las bases de datos sean iguales.

La reciente publicación de GDR tiene algunas características interesantes añadidas. De manera que suena como si utilizara su método de implementación integrado, puede generar un paquete de implementación que, al ejecutarlo, analizará la base de datos de destino y aplicará solo las diferencias.

Si tiene Team Studio - Team Suite o edición de desarrollo, puede utilizar la Edición de base de datos.

Pruébalo y es una gran evolución en el desarrollo de bases de datos.