¿Cómo debo abordar la migración de datos de un diseño de base de datos "malo" a un diseño utilizable?

Question

El proyecto actual que heredé principalmente gira en torno a una tabla no normalizada. Hay algunos intentos de normalización, pero las restricciones necesarias no se pusieron en práctica.

Ejemplo: en la tabla Proyecto, hay un nombre de cliente (entre otros valores) y también hay una tabla de clientes que solo contiene nombres de clientes [sin claves en ninguna parte]. La tabla de clientes solo se usa como un conjunto de valores para ofrecer al usuario al agregar un nuevo proyecto. No hay una clave principal en la tabla de clientes o una clave externa.

"Patrones de diseño" como este es común a través del estado actual de la base de datos y en las aplicaciones que lo utilizan. Las herramientas que tengo a mi disposición son SQL Server 2005, SQL Server Management Studio y Visual Studio 2008. Mi enfoque inicial ha sido determinar manualmente qué información necesita normalización y ejecutar consultas Select INTO. ¿Hay un mejor enfoque que caso por caso o de todos modos esto podría ser automático?

Editar: Además, he descubierto que un "número de orden de trabajo" no es una identidad de campo (Autonumérico, único) y que se generan de forma secuencial y son únicos para cada orden de trabajo. También hay algunas lagunas en la numeración existente, pero todas son únicas. ¿Es el mejor método para escribir un procedimiento de almacenamiento generar filas ficticias antes de migrar?

Answer 1

¿El mejor enfoque para migrar a un diseño utilizable? CUIDADOSAMENTE

A menos que esté dispuesto a romper (y corregir) todas las aplicaciones que actualmente usan la base de datos, sus opciones son limitadas, porque no puede cambiar mucho la estructura existente.

Antes de comenzar, piense detenidamente acerca de sus motivaciones: si tiene un problema existente (un error que corregir, una mejora), proceda lentamente. Sin embargo, rara vez vale la pena andar con un sistema de producción en funcionamiento solo para lograr una mejora que nadie más notará jamás. Tenga en cuenta que esto puede jugar a su favor: si hay un problema existente, puede señalarle a la administración que la manera más económica de arreglar las cosas es modificar la estructura de la base de datos en esta forma. Esto significa que tiene soporte administrativo para los cambios y (con suerte) su copia de seguridad si algo se torna en forma de pera.

Algunos pensamientos prácticos ...

hacer un cambio a la vez ... yúnica un cambio. Asegúrese de que cada cambio sea correcto antes de continuar. El viejo proverbio de "medir dos veces, cortar una vez" es relevante.

Automatizar Automatizar Automatizar ... Nunca haga los cambios en el sistema de producción "en vivo" utilizando SQL Server Management Studio. Escribir scripts SQL que realicen todo el cambio de una vez; desarrollar y probar estos en contra de una copia de la base de datos para asegurarse de que los haga bien. No utilice la producción como su servidor de prueba: podría ejecutar accidentalmente el script en contra de la producción; use un servidor de prueba dedicado (si el tamaño de la base de datos está bajo 4G, use SQL Server Express ejecutándose en su propia caja).

Copias de seguridad ... el primer paso en cualquier secuencia de comandos debe ser realizar una copia de seguridad de la base de datos, de modo que tenga un retroceso si algo sale mal.

Documentación ... si alguien viene a ti en doce meses, preguntando por qué característica X de su aplicación se rompe, tendrá un historial de los cambios exactos realizados en la base de datos para ayudar a diagnóstico y reparación . El primer buen paso es mantener todos los scripts de cambio.

Keys ... generalmente es una buena idea mantener las claves primarias y externas abstractas, dentro de la base de datos y no reveladas a través de la aplicación. Las cosas que parecen claves a nivel empresarial (como su número de orden de trabajo) tienen la inquietante costumbre de tener excepciones. Introduzca sus claves como columnas adicionales con restricciones apropiadas, pero no cambie las definiciones de las existentes.

¡Buena suerte!

Answer 2

No puedo pensar en una forma sensata de automatizar esto .... alguna entrada humana es clave en tales refactorizaciones, si quieres que la salida sea útil.

Número de orden de trabajo Re; asumiendo que quiere que esto continúe siendo una columna de IDENTIDAD; ¿puede quizás llenar los datos, encontrar el más grande y luego usar ALTER TABLE para hacerlo IDENTIDAD? No tengo ninguna herramienta TSQL a mano, por lo que no puedo probar, desafortunadamente. Alternativamente, simplemente considérelo una clave natural .

Answer 3

1. Crea la nueva base de datos de la manera que crees que debería estructurarse.
2. crear una tabla ImportError en la nueva base de datos con columnas como "oldid" y "errorDesc"
3. escribir un guión sencillo, procesal, legibles que los intentos para seleccionar una fila de la estructura de edad y la inserta en la nueva estructura. Si falla una inserción, registre un error lo más específico posible en la tabla importError (específicamente, por qué falló la inserción).
4. Ejecute la secuencia de comandos.
5. Validar los datos nuevos. Compruebe si hay errores registrados en la tabla importError. Si los datos no son válidos o hay errores, refactorice su script y ejecútelo de nuevo, posiblemente modificando su nueva estructura de base de datos cuando sea necesario.
6. Repita los pasos 1-5 hasta que tenga un script de conversión sólido.

El resultado de este proceso será que usted tiene: a) una nueva estructura db que se valida contra la estructura de edad y probado contra el "pragmatismo"; b) un registro de posibles problemas que puede necesitar para codificar (como errores que no se pueden solucionar con la conversión porque requieren una concesión en el esquema que no desea)

(podría tener en cuenta que es útil escribir el guión en el lenguaje de programación/scripting de su elección, en lugar de, por ejemplo, SQL.)

Answer 4

Recomiendo el uso de procedimientos almacenados para ayudar en el proceso de traducción.

Específicamente:

1. Uno por uno, reemplazar consultas utilizadas en el código con los procedimientos almacenados. Como parte del reemplazo, escriba las pruebas de unidad (o integración) contra los procedimientos almacenados directamente. Considere una clase auxiliar de código StoredProcs para consolidar allí el acceso a la base de datos.
2. Después de que todas las consultas sean ampliadas, puede refactorizar la base de datos, usando esas pruebas unitarias para asegurarse de que no está cambiando el comportamiento esperado.
3. Ventaja adicional: tendrá esas pruebas unitarias para protegerse contra futuras roturas.

Answer 5

No indicó si necesita mantener la interfaz de la aplicación actual, o si planea reescribir las consultas en la aplicación.

De cualquier manera, me

• diseñar el nuevo esquema
• escritura lotes de T-SQL, utilizando los cursores cuando sea necesario, para migrar los datos

cursores, aunque no es la primera opción en consultas operativas, son excelentes para este tipo de aplicaciones, ya que puede realizar la tarea de una manera muy estructurada. Estas secuencias de comandos tienden a ser muy legibles, lo cual es importante cuando no funciona de inmediato y hay varias iteraciones.

Answer 6

Puede usar SQL Server Integration Services (SSIS) que es parte de SQL Server 2005 para ayudarlo con la migración. Se utiliza para transferir datos de una forma a la otra:

http://en.wikipedia.org/wiki/SQL_Server_Integration_Services http://www.microsoft.com/sqlserver/2005/en/us/integration-services.aspx

Answer 7

sólo para añadir un toque sencillo. Cuando tenga su diagrama de relación de entidad en un A4 o A3 delante de usted, la normalización adecuada significará que no habrá muchas relaciones. Compruebe esto book or at least the site también.