Consejos para refactorizar un esquema de base de datos obsoleto [cerrado]
https://stackoverflow.com/questions/104380
-
01-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPregunta
Estar atrapado con un esquema de base de datos heredado que ya no refleja su modelo de datos es la pesadilla de todo desarrollador.Sin embargo, con todo lo que se habla de refactorizar código para facilitar el mantenimiento, no he oído mucho sobre la refactorización de esquemas de bases de datos obsoletos.
¿Cuáles son algunos consejos sobre cómo realizar la transición a un esquema mejor sin romper todo el código que depende del anterior?Propondré un problema específico que tengo para ilustrar mi punto, pero no dude en dar consejos sobre otras técnicas que hayan demostrado ser útiles; probablemente también serán útiles.
Mi ejemplo:
Mi empresa recibe y envía productos.Ahora, un recibo de producto y un envío de producto tienen datos muy diferentes asociados, por lo que los diseñadores de la base de datos original crearon una tabla separada para recibos y envíos.
En el año que llevo trabajando con este sistema, me he dado cuenta de que el esquema actual no tiene ningún sentido.Después de todo, tanto un recibo como un envío son básicamente una transacción, cada uno implica cambiar la cantidad de un producto, en el fondo solo el signo +/- es diferente.De hecho, con frecuencia necesitamos encontrar la cantidad total que el producto ha cambiado durante un período de tiempo, un problema para el cual este diseño es francamente intratable.
Obviamente, el diseño apropiado sería tener una única tabla de Transacciones con el Id. como clave externa de una tabla ReceiptInfo o ShipmentInfo.Desafortunadamente, el esquema incorrecto ya ha estado en producción durante algunos años y tiene cientos de procedimientos almacenados y miles de líneas de código borradas.Entonces, ¿cómo puedo hacer la transición del esquema para que funcione correctamente?
Solución
Aquí hay un catálogo completo de refactorizaciones de bases de datos:
Otros consejos
Es algo muy difícil de solucionar;Un par de opciones rápidas después de refactorizar la base de datos son:
Este libro (Refactorización de bases de datos) Ha sido un regalo de Dios para mí al tratar con esquemas de bases de datos heredados, incluso cuando tuve que lidiar con casi exactamente el mismo problema para nuestra base de datos de inventario.
Además, contar con un sistema para rastrear los cambios en el esquema de la base de datos (como una serie de scripts de modificación almacenados en el repositorio de control de fuente) ayuda enormemente a descubrir las dependencias del código a la base de datos.
Los procedimientos almacenados y las vistas son tus amigos aquí.Incluso si el sistema no los usa, cámbielo para usarlos y luego refactorice la base de datos que se encuentra debajo.
Sus recibos y envíos se convierten en vistas.
Cuidado, los recibos y los envíos son en realidad dos bestias muy diferentes en la mayoría de los sistemas con los que he trabajado.Los recibos están vinculados a los proveedores, mientras que los envíos están vinculados a los clientes (o ubicaciones del cliente/destino de envío).A nivel de inventario, suelen estar representados de la misma manera.
¿Todo el acceso a los datos está limitado a los procedimientos almacenados?De lo contrario, la tarea podría resultar casi imposible.Si es así, solo debe asegurarse de que sus scripts de migración de datos funcionen bien al realizar la transición del esquema antiguo al nuevo, y luego asegurarse de que sus procedimientos almacenados respeten sus entradas y salidas.
Esperemos que ninguno de ellos tenga consultas "select *".Si es así, use 'sp_help tablename' para obtener la lista completa de columnas, cópiela y reemplace cada * con la lista completa de columnas, solo para asegurarse de no romper el código del cliente.
Recomendaría realizar los cambios gradualmente y realizar muchas pruebas de integración.Es difícil hacer una remodelación importante sin introducir algunos errores.
Lo primero es crear el esquema de la tabla.Ya hice eso para una base de datos heredada usando Enterprise Architect.Puede seleccionar la base de datos y le creará todas las tablas/campos.Luego, deberás dividir todo en categorías.Por ejemplo, todos sus productos de recepción y envío juntos, artículos de clientes en otra categoría.Una vez que todo esté claro, podrá refactorizar el campo creando una nueva tabla, una nueva versión y nuevos campos.Por supuesto, esto necesitará muchos cambios si se accede a todo sin un procedimiento almacenado.
No creo que sea obvio que la identificación de la tabla de transacciones deba ser una clave externa para ReceiptInfo o ShipmentInfo.Piense al revés.En un modelo orientado a objetos, debe tener una tabla de transacciones y ReceiptInfo o ShipmentInfo deben tener una clave externa para la tabla de transacciones.Si tiene suerte, solo habrá 1 o 2 puntos en el código donde se realicen nuevos registros en ReceiptInfo o ShipmentInfo.Allí debe agregar un código donde agrega una entrada en la tabla Transacción y luego crear la entrada en ReceiptInfo o ShipmentInfo con la clave externa para Transacción.
A veces puede crear tablas nuevas que tengan mejores estructuras y luego crear vistas con los nombres de las tablas antiguas, pero basadas en los datos de las tablas nuevas.De esa manera, su código no se rompe mientras comienza a pasar a una mejor estructura.Sin embargo, tenga cuidado con esto, ya que a veces pasa de una tabla no relacional a una estructura relacional donde tiene varios registros mientras el código espera solo uno.Esto es especialmente cierto si tiene desarrolladores que utilizan subconsultas.
Luego, a medida que se cambie cada cosa, se alejará de las vistas a la tabla real.Eventualmente puedes abandonar las vistas.Esto al menos le permite trabajar de forma incremental para mantener las cosas funcionando a medida que las mueve, pero comenzar a arreglar las cosas para usar un mejor diseño.
