tablas - La última pesadilla de base de datos heredada de MySQL
mysql union group by (4)
¿No puede usar el código existente que accede a esta base de datos y adaptarla a sus necesidades? Por supuesto, el código debe ser horrible, pero podría manejar la estructura de la base de datos por usted, ¿no? Con suerte, puedes concentrarte en hacer tu trabajo en vez de jugar al arqueólogo.
Tabla 1: Todo, incluido el fregadero de la cocina. Fechas en el formato incorrecto (último año para que no pueda ordenar en esa columna), Números almacenados como VARCHAR, direcciones completas en la columna ''calle'', nombre y apellido en la columna de primer nombre, ciudad en la columna de apellido, direcciones incompletas, Filas que actualice las filas anteriores moviendo datos de un campo a otro en función de un conjunto de reglas que ha cambiado a lo largo de los años, registros duplicados, registros incompletos, registros de basura ... lo que sea ... oh, y por supuesto, no un TIMESTAMP o PRIMARY Columna clave a la vista.
Table2: Cualquier esperanza de normalización se fue por la ventana al abrir este bebé. Tenemos una fila para cada entrada Y actualización de filas en la tabla uno. Entonces duplicados como no hay mañana (800MB vale la pena) y columnas como Phone1 Phone2 Phone3 Phone4 ... Phone15 (no se llaman teléfono. Lo uso para ilustración) La clave foriegn es ... bueno, adivina. Hay tres candidatos según el tipo de datos en la fila de la tabla1
Tabla 3: ¿Puede empeorar? Oh si. La "clave foránea es una combinación VARCHAR de columna de guiones, puntos, números y letras! Si eso no proporciona la coincidencia (que a menudo no), entonces una segunda columna de código de producto similar debería. Columnas que tienen nombres que llevan NO hay correlación con los datos dentro de ellos, y el obligatorio Phone1 Phone2 Phone3 Phone4 ... Phone15. Hay columnas Duplicadas de Table1 y no una columna TIMESTAMP o PRIMARY KEY a la vista.
Tabla 4: se describió como un trabajo en progreso y sujeto a cambios en cualquier momento. Es essentailly simlar a los demás.
En cerca de 1m filas esto es un GRAN lío. Afortunadamente, no es mi gran desastre. Desafortunadamente, tengo que sacar un registro de composición para cada "cliente".
Inicialmente diseñé una traducción de cuatro pasos de la Tabla1 agregando una LLAVE PRIMARIA y convirtiendo todas las fechas en formato ordenable. Luego, un par de pasos más de consultas que devolvieron los datos filtrados hasta que tuve Table1 donde podría usarlo para extraer de las otras tablas para formar el compósito. Después de semanas de trabajo, lo reduje a un paso usando algunos trucos. Así que ahora puedo apuntar mi aplicación al desorden y sacar una buena mesa limpia de datos compuestos. Afortunadamente, solo necesito uno de los números de teléfono para mis propósitos, así que normalizar mi mesa no es un problema.
Sin embargo, aquí es donde comienza la verdadera tarea, porque todos los días cientos de empleados agregan / actualizan / eliminan esta base de datos de formas que no desea imaginar y todas las noches debo recuperar las nuevas filas.
Como las filas existentes en cualquiera de las tablas se pueden cambiar, y como no hay columnas TIMESTAMP ON UPDATE, tendré que recurrir a los registros para saber qué ha pasado. Por supuesto, esto supone que hay un registro binario, que no existe.
Al presentar el concepto cayó como un globo de plomo. También podría haberles dicho que sus hijos van a tener que someterse a una cirugía experimental. No son exactamente de alta tecnología ... en caso de que no te hayas reunido ...
La situación es un poco delicada, ya que tienen información valiosa que mi compañía quiere desesperadamente. He sido enviado por la alta gerencia de una gran corporación (ya sabes cómo son) para "hacer que suceda".
No puedo pensar en otra forma de manejar las actualizaciones nocturnas, que analizar el archivo de registro bin con otra aplicación, averiguar qué han hecho a esa base de datos durante el día y luego componer mi tabla en consecuencia. Realmente solo necesito mirar su mesa1 para descubrir qué hacer con mi mesa. Las otras tablas solo proporcionan campos para eliminar el registro. (Usar MASTER SLAVE no ayudará porque tendré un duplicado del desorden).
La alternativa es crear un hash único para cada fila de su tabla1 y crear una tabla hash. Luego revisaba toda la base de datos todas las noches para verificar si coinciden los hashs. Si no lo hicieran, leería ese registro y verificaría si existe en mi base de datos; si lo hiciera, lo actualizaría en mi base de datos; si no fuera así, sería un nuevo registro y lo INSERTARÍA. Esto es feo y no rápido, pero el análisis de un archivo de registro binario tampoco es bonito.
He escrito esto para ayudar a aclarar el problema. Con frecuencia, contárselo a alguien más ayuda a aclarar el problema y hace que una solución sea más obvia. ¡En este caso, tengo un gran dolor de cabeza!
Tu opinion sería muy apreciada.
Los archivos de registro (registros binarios) también fueron mi primer pensamiento. Si supieras cómo hicieron las cosas, te estremecerías. Para cada fila hay muchas entradas en el registro a medida que se agregan y cambian piezas. ¡Es ENORME! Por ahora me decidí por el enfoque Hash. Con un poco de paginación inteligente de memoria de archivos, esto es bastante rápido.
No soy una persona MySQL, así que esto está saliendo del campo izquierdo.
Pero creo que los archivos de registro pueden ser la respuesta.
Afortunadamente, solo necesitas saber 2 cosas del registro.
Necesita el registro / rowid, y necesita la operación.
En la mayoría de los DB, y supongo que MySQL, hay una columna implícita en cada fila, como un rowid o recordid, o lo que sea. Es el número de fila interno utilizado por la base de datos. Esta es su clave primaria "gratuita".
Luego, necesitas la operación. En particular, si se trata de una operación de inserción, actualización o eliminación en la fila.
Usted consolida toda esta información, en orden cronológico, y luego la ejecuta.
Para cada inserción / actualización, seleccione la fila de su base de datos original e inserte / actualice esa fila en su base de datos de destino. Si se trata de una eliminación, entonces eliminas la fila.
No te importan los valores de campo, simplemente no son importantes. Haz toda la fila.
Es de esperar que no deba tener que "analizar" los archivos de registro binarios, MySQL ya debe tener rutinas para hacer eso, solo necesita encontrar y descubrir cómo usarlos (incluso puede haber alguna útil utilidad de "registro de volcado" que pueda usar )
Esto le permite mantener el sistema bastante simple, y solo debe depender de su actividad real durante el día, en lugar del tamaño total de la base de datos. Finalmente, luego puede optimizarlo haciéndolo "más inteligente". Por ejemplo, tal vez inserten una fila, luego la actualicen y luego la eliminen. Sabrías que puedes ignorar esa fila por completo en tu repetición.
Obviamente, esto requiere un poco de conocimiento arcano para leer los archivos de registro, pero el resto debería ser sencillo. Me gustaría pensar que los archivos de registro también tienen una marca de tiempo, por lo que puede saber si desea trabajar en filas "a partir de hoy", o en el intervalo de fechas que desee.
es posible que pueda utilizar la herramienta mk-table-sync de maatkit para sincronizar una base de datos provisional (después de todo, su base de datos es muy pequeña). Esto "duplicará el desastre"
A continuación, puede escribir algo que, después de la sincronización, haga varias consultas para generar un conjunto de tablas más sanas que luego podrá informar.
Imagino que esto podría hacerse a diario sin un problema de rendimiento.
Hacerlo todo en un servidor diferente evitará afectar la base de datos original.
El único problema que puedo ver es si algunas de las tablas no tienen claves principales.