¿Cuáles son las mejores prácticas para retirar las columnas de bases de datos obsoletas? [cerrado]

Si desea conservar los datos, entonces no está obsoleto. Solo déjalo donde está. Está bien si alguna clase asignada a una tabla no asigna cada columna.

Está bien, entonces tu situación es que quieres que las filas antiguas tengan la propiedad C, pero las nuevas no.

Esto es equivalente a tener una relación de herencia de clase

class All
{
    string A;
    string B;
}

class Old : All
{
    string C;
}

class New : All
{
    string D;
}

que representarías en la base de datos con tres tablas con relaciones 1 a 1

table All
    id varchar
    A varchar
    B varchar

table Old
    id varchar
    C  varchar

table New
    id varchar
    D  varchar

Por lo tanto, podría crear un script de migración para crear la nueva tabla anterior, copiarle los datos de ID y C y eliminar la columna C de la tabla Todo.

Actualizando su código como se requiere con el nuevo sql;

Alternativamente, si solo necesita poder consultar los datos antiguos de C, podría crear una nueva tabla de archivo con A, B, C, copiar todos los datos y eliminar la columna C, agregar el D col a su 'En vivo' mesa

Si el almacenamiento de datos podría ser una preocupación, entonces divida las tablas: tecla / A / B tecla / C tecla / D

Puede acceder a través de una vista (definición de la ubicación de los datos en la base de datos) o cambiando la definición de ORM.

Este no es el más eficaz (se trata de una unión), pero puede presentar cualquier combinación de A / B / C / D a lo largo del tiempo sin cambiar el almacenamiento subyacente & dependiendo de tus patrones de acceso reales puede ser suficiente.

Es posible que no tenga la suerte de tener tiempo de inactividad, reestructurar tablas, etc. en un sistema de producción.

La ejecución del acceso a través de la vista le permite cambiar de A / B / C a A / B / C / D a A / B / D en la tabla subyacente con un cambio mínimo y sin movimiento de datos. Una vista será transparente para la lógica de lectura y si su dbms admite funciones o vistas actualizables, también será transparente para la lógica de escritura.

Realmente creo que su decisión reflejará muchas de las preocupaciones del mundo real: 1) ¿Cuáles son los tipos de datos C & re 2) los volúmenes de datos relativos recolectados para C / D 3) Superposición relativa de los datos C / D en comparación con las entradas puramente C o D 4) Disponibilidad y duración de la ventana de inactividad / mantenimiento 5) Soporte DBMS para vistas actualizables 6) La conveniencia de mantener los detalles de la estructura física de la base de datos en el ORM frente a la transparencia mediante la presentación a través de las vistas / funciones en la base de datos (donde es igual para todas las aplicaciones que acceden, no solo la actual)

Mi respuesta prefirió para tipos de datos grandes / complejos para (1), poca superposición para (3) y tiempo de inactividad mínimo para (4), idealmente con buena compatibilidad con dbms en (5) y múltiples aplicaciones que acceden a los datos en (6)

Pero no hay correcto / incorrecto para muchas alternativasS: - Comience con A / B / C, luego agregue D, ajustando ORM, aún más tarde suelte la columna C - Comience con A / B / C / D & ignorar nulos etc. Creo que, considere su solución y amp; lo que usted sabe de su propósito / ciclo de vida previsto, realice algunos modelos de tamaño / volumen & espere cambiar las cosas más tarde ya que no todo cambiará como se espera.

Eliminando referencias & huérfano de los datos es una opción de bajo riesgo.

Siempre hay posibles usos desconocidos 'backdoor' de los datos que pueden o no ser importantes para exponer al eliminar la columna.

Dependiendo del contenido de la columna C, podría haber un problema menor de rendimiento cuando la base de datos realiza exploraciones completas de la tabla o intenta extraer toda la tabla en la memoria durante las combinaciones si el optimizador considera que es más eficiente que usar índices.

Las aplicaciones pueden estar leyendo la tabla completa varias veces en lugar de columnas seleccionadas, pero si está utilizando un ORM exclusivamente, es poco probable.

Hay muchas cosas que considerar aquí, pero es posible que desee agregar una vista para superponer la tabla en lugar de hacer cambios en la tabla directamente. De esa forma, solo la vista debe cambiar.

No sé Django ORM, pero podría ser una posibilidad.

• Tienes una tabla A con las columnas a, b, c.
• Cree una nueva tabla B con las columnas a, b, d.
• Migre sus datos a la Tabla B.
• Mueva sus claves externas a la tabla A a la tabla B.

Ahora puede usar la Tabla B y aún tiene sus datos antiguos como referencia.