Normalmente es raro ver una tabla de datos de mas de cien campos.

Hace unos doce años me tocó modificar un sistema para Lucent Technologies que usaban para dar seguimiento a sus labores para Alestra y AT & T.

En aquella época acababa yo de salir de las gaseras, y justamente se llevaba tiempo trabajando con Eduardo en la primera Razón social. Nunca supe que pasó en cuanto al diseño pero un día me dicen que tenian problemas con un «brinco de registros» en un software de Visual Basic 5.0 para MSSQL 6.5 que era MARAVILLOSO en concepto, que se le había desrrollado y puesto a Lucent y en el que no tuve que ver en su formación.

Al poner manos a la obra resultó que como pensé, los programadores de Eduardo estaban usando DAO en lugar de ADO (y una orden en RDO que por entonces era imposible hacer en ADO de Alter Tables). El problema se debía a que los programadores esperaban 7.0 y se encontraron con problemas del collation.

Pero como iba diciendo, ya que arreglé el software y con tiempo libre por no estar en las gaseras, revisé con calma la base de datos y se usaba una tabla con mas de 700 campos.

El problema era único y la respuesta era eficiente y manejarlo por maestro detalle era de locos. En pocas palabras el objetivo del programa era controlar unos 600 datos de una «hoja central» donde guardaban todo el control de calidad y numeros varios de las ordenes de trabajo. Y no todas las personas, de todo el mundo, podían ver todos los campos, y algunas personas tenían derechos de escritura sobre algunos campos. Así que lo que se hacía era que, el instalador jefe por ejemplo tenía una vista de supervisión donde el y solo el podía poner la fecha de terminación, pero no veía nada de aduaanas, y el agente aduanal por decir algo, podía dar alta de las columnas aduanales relacionadas con la orden de trabajo.

A final de cuentas era una sola tabla consultada por unos cuarenta perfiles diferentes de usuarios que tenian acceso de consulta a solo lo que debían ver. Era correcto hacerlo de ese modo porque cada tres o cuatro semanas salían nuevos controles de calidad y mantener un maestro detalle para sesenta perfiles era una labor estúpida. Mucho mas fácil hacer que los nuevos campos fueran invisibles para todos, e irles dando los derechos como si fuera una red Banyan Vines ( http://en.wikipedia.org/wiki/Banyan_VINES ) en base a negación inversa

Después de aquello, nunca pensé que me iba a encontrar con la necesidad de hacer mas de 100 campos.

Justamente me estoy peleando con un software de control de produciión con dos líneas de producto pero que maneja mas de 400 parámetros dependiendo de las diferentes lineas de producción. Y como los totales deben ir en el resumen principal, lo mas sensato era una sola tabla, sobre todo porque simplifica los 200 campos informativos en sumas de javascript y se está simulando una hoja de excel que manejaban antes.

Mañana o pasado tengo que generar elementos de muestra simulando un año de producción, y empezar a graficar la captura.

Esta semana va a ser de las mas pesadas del mes. Espero para finales del 24 estar mas tranquilo.