Si tuviera un DBA que fuera responsable de implementar las bases de datos en un entorno en vivo, ¿qué le daría? ¿Una secuencia de comandos de creación de base de datos o una copia de seguridad que podría restaurar en una base de datos existente? ¿Qué tipo de ventajas/desventajas hay? (Estamos usando MSSQL2000 y MSSQL2005)Despliegue de la base de datos: secuencia de comandos o copia de seguridad
Aunque estoy de acuerdo con la primera sugerencia despliegue de Juan de utilizar una copia de seguridad de base de datos, me quedo con la idea de, al menos, tener la secuencia de comandos disponibles para su revisión para permitir la comprobación de estándares de codificación, evaluación del desempeño, etc.
Si Estoy pensando en algo que ya ha sido revisado, entonces la copia de seguridad/restauración es una opción perfecta para la primera implementación, más aún si hay datos de configuración que han sido "organizados" en esa base de datos. Esta ayuda para evitar declaraciones insertadas largas o complejas.
Es un hecho que las versiones más allá de la primera van a ser secuencias de comandos. En nuestro entorno, necesitamos notas de la versión para especificar el servidor, la instancia y la ruta a los scripts. Los scripts deben proporcionarse en orden numérico, separados en carpetas por la base de datos de destino, con un segundo conjunto de scripts de retrotracción. Incluso requerimos que cada script tenga una declaración USE en la parte superior para que no tengamos que preocuparnos por crear nuevos objetos en la base de datos maestra. ;)
El script de creación de DB es mejor: siempre puede abrir un bloc de notas y arreglarlo.
No estoy seguro de la opción de copia de seguridad pero con una secuencia de comandos de creación db el dba puede configurar la base de datos como quiera (tiene, permisos, etc.) y luego crear las tablas, etc. con la secuencia de comandos.
Prefiero un script para las implementaciones, son mucho menos intrusivas. Una restauración sobrescribirá toda la base de datos, datos y todo lo que probablemente no sea una buena idea en su entorno de producción.
Para la primera implementación de ; una copia de seguridad de la base de datos ... es tan rápido y fácil.
Si la base de datos ya está en vivo; tiene que ser una serie de scripts numerados. Personalmente, numere mis scripts y solo realizo cambios en la base de datos a través del script. Esto garantiza que todas las bases de datos estén sincronizadas, o se puede hacer que estén sincronizadas de manera realmente sencilla.
Algunas personas piensan que esto es una especie de anal ... pero nunca tendré un problema de implementación de producción.
Prefiero un script porque puede colocarlo en un repositorio y seguirlo. También puede ejecutarlo en un servidor remoto con bastante facilidad.
Utilice scripts bajo el control de código fuente, un beneficio lateral encantador es que crea un historial de búsqueda de cada objeto en la base de datos y es legible por el ser humano. Las copias de seguridad son cuadros negros: usted no sabe lo que le harán a su base de datos.
Me gustaría ir con los scripts: la combinación de legibilidad humana, compatibilidad mediante el control del código fuente y la posibilidad de gestionar fácilmente las actualizaciones de su motor de base de datos hacen que este sea el camino a seguir en nuestra organización.
Definitivamente vaya con scripts SQL, ya que se pueden controlar las versiones. Preferentemente, hágalos pequeños y tenga algún tipo de lote para ejecutarlos en un orden conocido (incrementalmente) para que sea fácil ejecutarlos en una base de datos que ya está en producción.
Una alternativa a las secuencias de comandos SQL es utilizar una infraestructura de migración. Usted especifica los cambios de la base de datos en pequeños pasos en el código fuente.El beneficio de un marco de migración es que un programador que no conoce SQL simplemente puede hacer cambios en la base de datos (sin embargo, esto no elimina la necesidad de conocer algunos principios básicos de la base de datos).
Son bastante explícitos acerca de cómo construir y desmontar una base de datos en los pasos incrementales. Esto hace que sea más fácil probar y volver a crear errores en diferentes versiones de un sistema o aplicación de base de datos.
Algunos ejemplos de marcos de migración, que yo sepa son:
La copia de seguridad está destinada a hacer una copia de seguridad de la base de datos. A medida que la base de datos crece, la portabilidad disminuye. Entonces un programador solo necesita un subconjunto de los datos. Por razones de seguridad, deberían tratar con datos de prueba en lugar de datos reales también. Es una buena práctica tener a mano un generador de datos de prueba para que los desarrolladores y probadores puedan probar su implementación sin dañar los datos en producción.
Si bien utilizar una copia de seguridad de la base de datos es una solución fácil para la implementación inicial, puede no ser una buena solución si se implementa en servidores que tienen configuraciones regionales diferentes que el servidor desde el que se realizó la copia de seguridad. Hemos utilizado este enfoque en el pasado y hemos tenido problemas después del hecho con conflictos de intercalación para nuestros clientes en el extranjero. Una copia de seguridad de la base de datos conserva su clasificación, mientras que una secuencia de comandos creará la base de datos en la intercalación predeterminada del servidor (a menos que usted lo especifique). Por este motivo, hemos pasado a los scripts para la implementación inicial y las actualizaciones posteriores. – Parmenion