Mi compañero de trabajo creó una tabla SQL de 96 columnas

Aquí estamos en 2010, ingenieros de software con 4 o 5 años o experiencia, aún diseñando tablas con 96 columnas de fracking.

Le dije que será una pesadilla.
Le mostré que tenemos que usar ordinales para interactuar MySQL con C #.
Le expliqué que las tablas con más columnas que filas son un gran olor.

Aún así, me sale "Será más sencillo de esta manera".

¿Qué tengo que hacer?

EDITAR *

Esta tabla contiene datos de sensores.
Tenemos sensor 1 con
Dynamic_D1X
Dynamic_D1Y
[...]

Dynamic_D6X
Dynamic_D6Y
[...]

EDIT2 *

Bueno, finalmente dejé ese trabajo. Es una señal cuando el otro programador se apaga durante meses en ese momento, es otra señal cuando la gerencia no se da cuenta de que esto es un problema

¿Tal vez lo hizo por una buena razón, como actuaciones o ROI? .

Lo mejor que puede hacer es hacerle preguntas. Con una cierta cantidad de "por qué" seguramente le hará comprender que probablemente esté equivocado por sí mismo (si es que realmente lo está).

Yo mismo tuve un caso que no está relacionado con el rendimiento sino con el retorno de la inversión (ROI). Tenía una tabla que contenía objetos que tenían un valor específico para cada hora de la semana (168 h en una semana). Tuvimos la opción de crear una tabla ObjectHour que contendría el valor, pero también una clave para el objeto y el número de día y número de hora. Pero también tuvimos la oportunidad de poner los 168 valores en la fila. Probablemente como lo que hizo tu colega.

Los desarrolladores estimaron ambas soluciones. La solución simple (168 columnas) fue mucho más barata que su contraparte bien diseñada. Para el mismo resultado exacto para el cliente.

Decidimos optar por la solución simple / más barata para enfocar nuestros esfuerzos en cosas más importantes como la seguridad.

Tendremos muchas oportunidades para mejorar eso en el futuro. El tiempo de comercialización era la prioridad para nosotros en ese momento.

Desafortunadamente, su desarrollador promedio todavía piensa en las bases de datos relacionales como grandes archivos planos. La única forma en que mejorarán es si alguien se hace cargo y lidera con el ejemplo. Hace poco encabecé un rediseño importante de un esquema importante en nuestra base de datos y seguí prácticas relacionales comunes. De repente, nuestros procedimientos almacenados eran más elegantes y todos los índices adecuados parecían encajar como si hubieran nacido para ello. El desarrollador impulsado por el ego nunca te creerá sin pruebas.

Algo similar se discutió anteriormente en StackOverflow .

En general, tener muchas columnas en una tabla no significa necesariamente que esté haciendo algo mal, pero definitivamente debería generar algunas señales de alerta para que observe de cerca el diseño. A veces, una mesa enorme es la elección correcta, pero en muchos casos, otras alternativas tienen más sentido. Por ejemplo, una opción es dividir el almacenamiento en dos tablas: una tabla que identifica sus entidades y otra tabla que es efectivamente un almacén de atributos clave / valor que describe esas entidades (por lo que puede terminar con un máximo de 96 filaspara cada entidad). Otros diseños son posibles también. Hable con sus compañeros de equipo y descubra qué solución es mejor dependiendo de la normalización de los datos, la legibilidad del código y la capacidad de mantenimiento (¿insertar declaraciones con 96 atributos para completar?), Implicaciones de rendimiento, con qué frecuencia se pueden agregar o cambiar nuevos atributos (columnas), qué tan escaso los datos son (¿cuántas de las 96 columnas se llenarán alguna vez y cuántas siguen siendo NULL?), y las implicaciones en los informes. Cualquier desarrollador debe poder justificar razonablemente sus decisiones de diseño y mostrar que el costo / beneficio de compensación (y sí, cada decisión de diseño es una compensación) está a su favor. Su responsabilidad no es quejarse ni criticar, sino proponer alternativas y asegurarse de que reflexionen sobre estos temas.

¿Está normalizado con 96 columnas? ¿Satisface el 1er, 2do, 3er etc. NF?

Puede ser que tenga 96 atributos separados para una entidad.

De lo contrario, haz que lea a Joe Celko en Simple Talk

Depende completamente.

Los diseños de DB normalizados / no normalizados tienen sus ventajas y desventajas.

Mi primer diseño de DB fue una cosa normalizada de belleza. Era flexible y extensible. También fue un PITA increíble para cualquiera, excepto yo mismo, para tratar en el nivel de código, y fue un PITA leve para mí.

Mi siguiente intento fue una estructura plana, y fue (a) mucho más rápido y (b) mucho más fácil de codificar. Y no será una gran tarea normalizar más después.

Por lo tanto, puede ser un olor, pero algún otro diseño de DB tendrá su propia variedad encantadora de olores.

Haz que lea este artículo sobre deuda técnica . Si todavía decide mantenerlo así, entonces al menos le ha ofrecido una opinión constructiva.

Mirando la publicación (editada), está claro que esta es una tabla mal desnormalizada. Que deberias hacer Tal como lo veo, tienes algunas opciones:

1. Grítele a su compañero de trabajo para aprender cómo hacer su trabajo. Es poco probable que sea productivo, pero probablemente convencerá a otros compañeros de trabajo de no meterse con usted. Una reputación como un maníaco que grita puede ser útil (no me preguntes cómo lo sé).
2. Grita al jefe que el compañero de trabajo es un idiota. Predecir el desastre, luego trabajar activamente para sabotear el proyecto. Culpe todo al diseño de la base de datos producido por un compañero de trabajo incompetente. Puede conducir directamente a ...
3. Dejar. Mejor si es tu idea, pero el # 2 puede llevar a la renuncia involuntaria. Trate de no raspar las rodillas sobre el asfalto / concreto / grava si es arrojado desde la ventana por un jefe y / o compañeros de trabajo enfurecidos. (Tenga en cuenta que el estudio previo es IMPORTANTE aquí. Sus posibilidades de supervivencia disminuyen notablemente si la oficina del jefe está por encima de la planta baja y se ve impulsado por la ventana. ¡ Planifique con anticipación! )
4. Beba mucho, o muévase a California y enciéndase (suponiendo que se apruebe la prop. Nada como unos pocos disparos y un tonto para mejorar la perspectiva de los compañeros de trabajo (o eso he oído). (Anuncio de servicio público: ¡NIÑOS! ¡Estas personas son profesionales! ¡NO intenten esto en casa!)

Comparte y Disfruta.

Voy a arriesgarme aquí y asumir que él va a cortar y pegar mucho código para trabajar con esta tabla "Nueva".

Si es así, probablemente no incurrirá en ninguna deuda técnica adicional. Acaba de dividir su parte de la deuda técnica y puede estar en camino a algún tipo de gran unificación de las cosas.

Si tiene una metodología probada y verdadera que requiere una cuestión de 96 columnas, considere los beneficios reales de hacerlo de una manera diferente en este caso particular. Si no hay ninguno, dele el beneficio de la duda, pero recuérdele que la próxima vez que quiera estar en la fase de planificación la próxima vez que haga lo que todos consideraríamos un movimiento bastante tonto.

Depende totalmente de los casos de uso de la aplicación que va a acceder al esquema, qué porción de datos se necesita a la vez. De alguna manera podría justificar el diseño de la tabla.

Lo enviaría a la edad de piedra y lo obligaría a usar archivos o al menos enseñarle a usar blobs.

Realmente, 96 columnas ... Eso no puede ser correcto, nunca. Quizás un ORM ayudaría. (A menos que necesite rendimiento pero luego puede tener a alguien que comprenda mejor DB para manejarlo)

Voy a ser rechazado por el infierno por esto, pero es exactamente por eso que separé las responsabilidades de modelado de datos e ingeniería de software en mi tienda. Los programadores rara vez parecen pensar en forma de conjuntos y en su lugar se centran en el uso de datos (en lugar de mantener la tercera forma normal, la indexación u otros problemas de rendimiento de la base de datos). Nosotros, como programadores, también tendemos a estar más en desacuerdo sobre esas decisiones arquitectónicas de la base de datos de lo que deberíamos, debido a nuestra inexperiencia en cuestiones de arquitectura / modelado de datos puros. En mi humilde opinión, me gusta que tengo arquitectos de datos y modeladores que toman los requisitos, crean tablas / procs / etc. y me dejo a cargo de los resultados.

Sin embargo, sin conocer las razones reales de este diseño (he trabajado en sensores climáticos que tienen más de 96 salidas numéricas diferentes = gran número de columnas de tabla) ... esto parece desahogarse.