tabla - exportar datos de sql server a excel
¿Cómo gestionar adecuadamente la implementación de la base de datos con proyectos de bases de datos SSDT y Visual Studio 2012? (4)
Estoy en la fase de investigación tratando de adoptar 2012 Proyectos de bases de datos en un pequeño proyecto existente. Soy un desarrollador de C #, no un DBA, así que no soy particularmente fluido con las mejores prácticas. He estado buscando en google y stackoverflow durante algunas horas pero todavía no sé cómo manejar algunos escenarios de implementación clave correctamente.
1) En el transcurso de varios ciclos de desarrollo, ¿cómo administro múltiples versiones de mi base de datos? Si tengo un cliente en v3 de mi base de datos y quiero actualizarlos a v8, ¿cómo puedo administrar esto? Actualmente administramos scripts de migración de datos y esquemas hechos a mano para cada versión de nuestro producto. ¿Todavía tenemos que hacer esto por separado o hay algo en el nuevo paradigma que lo respalde o reemplace?
2) Si el esquema cambia de tal manera que requiere que se muevan los datos, ¿cuál es la mejor manera de manejar esto? Supongo que algunos trabajos van en la secuencia de comandos Pre-Deployment para preservar los datos y luego la secuencia de comandos Post-Deploy los devuelve al lugar correcto. ¿Es ese el camino o hay algo mejor?
3) ¡Cualquier otro consejo u orientación sobre la mejor manera de trabajar con estas nuevas tecnologías también es muy apreciado!
ACTUALIZACIÓN: Mi comprensión del problema ha crecido un poco desde que originalmente hice esta pregunta y, aunque se me ocurrió una solución factible, no era la solución que esperaba. Aquí hay una nueva redacción de mi problema:
El problema que estoy teniendo es puramente relacionado con los datos. Si tengo un cliente en la versión 1 de mi aplicación y deseo actualizarlo a la versión 5 de mi aplicación, no tendría problemas para hacerlo si su base de datos no tuviera datos. Simplemente dejaría que SSDT compare inteligentemente los esquemas y migre la base de datos de una vez. Lamentablemente, los clientes tienen datos, por lo que no es tan simple. El esquema cambia de la versión 1 de mi aplicación a la versión 2 a la versión 3 (etc.) todos los datos de impacto. Mi estrategia actual para administrar datos requiere que mantenga un script para cada actualización de la versión (1 a 2, 2 a 3, etc.). Esto me impide pasar directamente de la versión 1 de mi aplicación a la versión 5 porque no tengo un script de migración de datos para ir directamente allí. El prospecto que crea scripts de actualización personalizados para cada cliente o que administra los scripts de actualización para pasar de cada versión a cada versión mayor es exponencialmente inmanejable. Lo que esperaba era que hubiera algún tipo de estrategia que SSDT permita que facilite la administración de los datos, incluso tan fácil como el esquema de las cosas. Mi experiencia reciente con SSDT no me ha dado ninguna esperanza de que exista tal estrategia, pero me encantaría saberlo de otra manera.
En mi experiencia de usar SSDT, la noción de números de versión (es decir, v1, v2 ... vX, etc ...) para las bases de datos se va un poco. Esto se debe a que SSDT ofrece un paradigma de desarrollo conocido como desarrollo de bases de datos declarativas, lo que significa que le dice a SSDT en qué estado desea que esté su esquema y luego deja que SSDT asuma la responsabilidad de compararlo con lo que ya tiene. En este paradigma, desaparece la idea de implementar v4, v5, etc.
Sus secuencias de comandos de implementación previa y posterior, tal como se indica correctamente, existen con el objetivo de administrar los datos.
Espero que ayude.
JT
He estado trabajando en esto yo mismo, y puedo decirte que no es fácil.
En primer lugar, para abordar la respuesta de JT, no puede descartar "versiones", incluso con la mecánica de actualización declarativa que tiene SSDT. SSDT hace un trabajo "bastante decente" (siempre que conozca todos los cambios y errores) de mover cualquier esquema de origen a cualquier esquema de destino, y es verdad que esto no requiere verión per se, pero no tiene idea de cómo administrarlo " movimiento de datos "(al menos no que yo pueda ver!). Entonces, al igual que DBProj, lo dejaste a tus propios dispositivos en los guiones Pre / Post. Debido a que las secuencias de comandos de movimiento de datos dependen de un estado de esquema de inicio y fin conocido, no puede evitar la creación de versiones de la base de datos. Los scripts de "movimiento de datos", por lo tanto, se deben aplicar a una instantánea versionada del esquema, lo que significa que no se puede actualizar arbitrariamente un DB de v1 a v8 y esperar que funcionen los scripts de movimiento de datos v2 a v8 (presumiblemente, no se necesita una secuencia de comandos de movimiento de datos v1).
Lamentablemente, no puedo ver ningún mecanismo en la publicación SSDT que me permita manejar este escenario de una manera integrada. Eso significa que tendrás que agregar tu propio scafolding.
El primer truco es rastrear las versiones dentro de la base de datos (y el proyecto SSDT). Empecé a usar un truco en DBProj, y lo llevé a SSDT, y después de investigar un poco, resulta que otros están usando esto también. Puede aplicar una propiedad extendida DB a la base de datos (llámela "BuildVersion" o "AppVersion" o algo así) y aplique el valor de la versión a la misma. A continuación, puede capturar esta propiedad extendida en el proyecto SSDT en sí mismo, y SSDT lo agregará como una secuencia de comandos (a continuación, puede verificar la opción publicar que incluye propiedades extendidas). Luego uso las variables SQLCMD para identificar las versiones de origen y destino que se aplican en el pase actual. Una vez que identifica el delta de versiones entre el origen (instantánea del proyecto) y el objetivo (db del objetivo a punto de actualizarse), puede encontrar todas las instantáneas que se deben aplicar. Desafortunadamente, esto es complicado de hacer desde el despliegue de SSDT, y es probable que deba moverlo a la compilación o al pipeline de implementación (utilizamos implementaciones automatizadas de TFS y tenemos acciones personalizadas para hacer esto).
El siguiente obstáculo es mantener instantáneas del esquema con sus secuencias de comandos de movimiento de datos asociadas. En este caso, ayuda a que los guiones sean lo más idempotentes posible (es decir, puede volver a ejecutar los guiones sin ningún efecto secundario negativo). Ayuda a dividir las secuencias de comandos que se pueden volver a ejecutar de forma segura a partir de secuencias de comandos que deben ejecutarse una sola vez. Estamos haciendo lo mismo con los datos de referencia estáticos (tablas de búsqueda o de diccionario); en otras palabras, tenemos una biblioteca de scripts MERGE (uno por tabla) que mantienen sincronizados los datos de referencia, y estos scripts se incluyen en la publicación -deployment scripts (a través del comando SQLCMD: r). Lo importante a tener en cuenta aquí es que debe ejecutarlos en el orden correcto en caso de que alguna de estas tablas de referencia tenga referencias FK entre sí. Los incluimos en el script principal posterior a la implementación en orden, y es útil que creamos una herramienta que genere estos scripts para nosotros; también resuelve el orden de dependencia. Ejecutamos esta herramienta de generación al final de una "versión" para capturar el estado actual de los datos de referencia estáticos. Todos los otros guiones de movimiento de datos básicamente serán un caso especial y muy probablemente serán de un solo uso. En ese caso, puede hacer una de estas dos cosas: puede usar una instrucción IF contra la versión de db build / app, o puede borrar las secuencias de comandos de 1 vez después de crear cada paquete de instantáneas.
Es útil recordar que SSDT desactivará las restricciones de verificación FK y solo las volverá a habilitar después de que se ejecuten las secuencias de comandos posteriores a la implementación. Esto le da la oportunidad de poblar nuevos campos no nulos, por ejemplo (por cierto, debe habilitar la opción para generar valores predeterminados temporales "inteligentes" para columnas que no sean nulas para que esto funcione). Sin embargo, las restricciones de comprobación de FK solo están deshabilitadas para las tablas que SSDT está recreando debido a un cambio de esquema. Para otros casos, usted es responsable de garantizar que las secuencias de comandos de movimiento de datos se ejecuten en el orden correcto para evitar las reclamaciones de restricciones de cheques (o que las inhabilite / vuelva a habilitar manualmente en sus scripts).
DACPAC puede ayudarlo porque DACPAC es esencialmente una instantánea. Contendrá varios archivos XML que describan el esquema (similar al resultado de compilación del proyecto), pero se congelarán en el tiempo en el momento en que lo cree. A continuación, puede usar SQLPACKAGE.EXE o el proveedor de implementación para publicar esa instantánea del paquete. Todavía no he descubierto cómo usar el control de versiones de DACPAC, porque está más vinculado a las aplicaciones de datos "registradas", por lo que estamos atascados en nuestro propio esquema de control de versiones, pero ponemos nuestra propia información de la versión en el nombre del archivo DACPAC.
Ojalá tuviera un ejemplo más concluyente y exhiutivo para proporcionar, pero aún estamos resolviendo los problemas aquí también.
Una cosa que realmente apesta de SSDT es que a diferencia de DBProj, actualmente no es extensible. Aunque hace un trabajo mucho mejor que DBProj en muchas cosas diferentes, no puede anular su comportamiento predeterminado a menos que pueda encontrar algún método dentro de las secuencias de comandos previos / posteriores para evitar un problema. Uno de los problemas que intentamos resolver en este momento es que el método predeterminado para volver a crear una tabla de actualizaciones (CCDR) realmente apesta cuando tienes decenas de millones de registros.
-UPPARACIÓN: No he visto esta publicación en algún momento, pero aparentemente ha estado activa últimamente, así que pensé en agregar un par de notas importantes: si está utilizando VS2012, la versión de SSDT de junio de 2013 ahora tiene datos. Herramienta de comparación integrada, y también proporciona puntos de extensibilidad, es decir, ahora puede incluir Colaboradores de compilación y Modificadores de plan de despliegue para el proyecto.
Realmente no he encontrado más información útil sobre el tema, pero he dedicado un tiempo a conocer las herramientas, jugando y jugando, y creo que he llegado a algunas respuestas aceptables a mi pregunta. Estas no son necesariamente las mejores respuestas. Todavía no sé si existen otros mecanismos o mejores prácticas para respaldar mejor estos escenarios, pero esto es lo que se me ocurrió:
Los scripts Pre y Post-Implementación para una versión dada de la base de datos solo se utilizan para migrar datos de la versión anterior. Al comienzo de cada ciclo de desarrollo, los scripts se limpian y, a medida que avanza el desarrollo, se completan con cualquier sql necesario para migrar con seguridad los datos de la versión anterior a la nueva. La única excepción aquí son los datos estáticos en la base de datos. Estos datos se conocen en tiempo de diseño y mantienen una presencia permanente en los scripts Post-Deploy en forma de sentencias MERGE de T-SQL. Esto ayuda a que sea posible implementar cualquier versión de la base de datos en un nuevo entorno con el último script de publicación. Al final de cada ciclo de desarrollo, se genera un script de publicación desde la versión anterior hasta la nueva. Este script incluirá sql generado para migrar el esquema y los scripts de implementación hechos a mano. Sí, sé que la herramienta Publicar se puede usar directamente en una base de datos, pero esa no es una buena opción para nuestros clientes. También conozco los archivos dacpac, pero no estoy seguro de cómo usarlos. El script de publicación generado parece ser la mejor opción que conozco para las actualizaciones de producción.
Entonces para responder a mis escenarios:
1) Para actualizar una base de datos de v3 a v8, tendría que ejecutar el script de publicación generado para v4, luego para v5, luego para v6, etc. Esto es muy similar a cómo lo hacemos ahora. Está bien entendido y los proyectos de bases de datos parecen hacer que la creación / mantenimiento de estos scripts sea mucho más fácil.
2) Cuando el esquema cambia desde debajo de los datos, los scripts Pre y Post-Implementación se utilizan para migrar los datos a donde necesita ir para la nueva versión. Los datos afectados están esencialmente respaldados en el script Pre-Deploy y puestos nuevamente en su lugar en el script Post-Deploy.
3) Todavía estoy buscando consejos sobre la mejor manera de trabajar con estas herramientas en estos escenarios y otros. Si tengo algo mal aquí, o si hay algún otro problema que deba tener en cuenta, ¡por favor hágamelo saber! ¡Gracias!
Solo quería decir que este hilo hasta ahora ha sido excelente.
He estado luchando con las mismas preocupaciones exactas y estoy tratando de abordar este problema en nuestra organización, en una aplicación heredada bastante grande. Hemos comenzado el proceso de avanzar hacia SSDT (en una sucursal de TFS) pero estamos en el punto donde realmente necesitamos comprender el proceso de implementación y administrar las migraciones personalizadas, y los datos de referencia / búsqueda, a lo largo del camino.
Para complicar aún más las cosas, nuestra aplicación tiene una base de código pero puede personalizarse por ''cliente'', por lo que tenemos aproximadamente 190 bases de datos con las que estamos tratando, para este proyecto, no solo 3 o más, probablemente sea normal. Hacemos implementaciones todo el tiempo e incluso configuramos nuevos clientes con bastante frecuencia. Ahora dependemos en gran medida de PowerShell con scripts de versiones incrementales de la vieja escuela (y scripts asociados para crear un nuevo cliente en esa versión). Planeo contribuir una vez que resolvamos todo esto, pero por favor comparte cualquier cosa que hayas aprendido. Creo que terminaremos manteniendo scripts de lanzamiento personalizados por versión, pero ya veremos. La idea de mantener cada script dentro del proyecto, e incluir una variable From y To SqlCmd es muy interesante. Si lo hiciéramos, probablemente lo eliminaríamos en el camino, borrando físicamente las secuencias de comandos de actualización realmente antiguas una vez que todo el mundo hubiera superado esa versión.
Por cierto - Nota al margen: sobre el tema de minimizar el desperdicio, también pasamos un montón de tiempo averiguando cómo automatizar el cumplimiento de las convenciones adecuadas de denominación / tipo de datos para columnas, así como generación automática para todas las claves primarias y extranjeras, basadas en las convenciones de nomenclatura, así como en las restricciones de índice y verificación, etc. La parte más difícil fue tratar con los "desviados" que no siguieron las reglas. Tal vez lo comparta también algún día si alguien está interesado, pero por ahora, tengo que continuar con esta historia de implementación, migración y datos de referencia. Gracias de nuevo. Es como si ustedes estuvieran hablando exactamente lo que estaba en mi cabeza y buscando esta mañana.