¿Son las relaciones más lentas que una mesa grande e ineficiente?

En mi trabajo, se me ha pedido que viole la primera forma normal (repetir grupos a través de columnas, usar valores vacíos / nulos) varias veces, "en aras de la potencia de procesamiento de la computadora". En pocas palabras, una tabla de "estudiantes" debe tener al menos 8 campos vacíos (por ejemplo, teléfonos: teléfono1, teléfono2, teléfono3 ...) en lugar de mi sugerencia: una tabla de "teléfono" que contiene un número de teléfono (y otros posibles metadatos) y la clave externa es el número de identificación del alumno. Mi jefe dice que es mejor almacenarlos de esa manera porque "hay menos ciclos de CPU y eso es importante en las plataformas web", en lugar de usar relaciones. Digo que, en el peor de los casos, es insignificante.

En ese ejemplo, usar relaciones (supongamos que las tablas están llenas de muchos registros en una aplicación web de tamaño mediano) es notablemente más lento que usar ese tipo de esquema de tabla.

— AeroCross
fuente

Creo que en realidad sería más rápido hacer lo que dice tu jefe, pero tienes la tarea posiblemente insoportable de asegurarte de no obtener anomalías de actualización. Pero podría crear mucho más trabajo de CPU si alguna vez necesita cambiar un dato que es común a la tabla (por ejemplo, cambie el código de área para todos los números de teléfono ...)

— Patrick

Dudo seriamente, en el hardware moderno, siempre que indexe sus claves foráneas que la CPU adicional podría ser medible, especialmente en el otro lado de un servidor web. En mi sitio tenemos mesas normalizadas y servimos bien al norte de 50,000 golpes / segundo sin sudar. ¡Dígale a su jefe que se adhiera al golf y le deje las decisiones técnicas a usted!

— Gaius

@Patrick ¿Crees que es considerablemente más rápido o solo un poco más rápido? Y creo que al igual que @Gaius: en el hardware moderno, incluso si es "más rápido", la ganancia de velocidad y durabilidad del hardware es insignificante.

— AeroCross

Creo que la mejora de la velocidad es intrascendente. Solo si tiene conjuntos de datos masivos y está haciendo uniones ridículas, vería una diferencia notable en el rendimiento.

— Patrick

No veo cómo alguien podría hacer tal declaración sin tener algunos hechos reales que lo respalden. Si sus consultas están vinculadas a la CPU, debería buscar formas de reducir ese cuello de botella.

Parece que su jefe siente que una base de datos desnormalizada funcionará mejor, pero no sé lo suficiente sobre su aplicación para decir si eso es correcto o no. ¿Cuál será el número esperado de eliminaciones, actualizaciones e inserciones para esta tabla?

Esperaría que un diseño tan desnormalizado pueda dar como resultado una cantidad reducida de tiempo de CPU, pero esperaría que la E / S de su disco aumentara. Y las lecturas físicas del disco serán mucho más caras que un ciclo de CPU, por lo tanto, ¿quizás su jefe tenga una métrica muy específica que cumplir (CPU) y, como resultado, quiera un diseño muy específico? Si es así, simplemente construiría lo que se solicita y mantendría métricas sobre el costo de la CPU para las consultas que se ejecutan. Si ve un aumento en el tiempo, es posible que desee sugerir algunos cambios de diseño.

De hecho, probablemente sea una buena idea obtener una lista de todas las métricas que su jefe quiere ver y rastrearlas a lo largo del tiempo.

— SQLRockstar
fuente

La cuestión es que él es de la vieja escuela, en sus días (¿20 años?) Tal vez eso era importante, como él propone, pero el hardware y el software de hoy en día es mucho, mucho más poderoso y, por diseño, es más rápido de esa manera. Sin embargo, es difícil tratar con alguien así, porque tiene más poder y el "hecho" empírico (pero anticuado) de que ES MÁS rápido, y debería considerarse de esa manera.

— AeroCross

entendido. intente que haga una lista de las métricas (CPU, disco I? O) que desea medir y lo que considera aceptable. luego simplemente mida esos elementos y cuando las cosas salgan mal, podría ofrecer algunas alternativas. de esa manera puedes implementar un mejor diseño sin luchar; solo deje que su diseño se pruebe con el tiempo. es un ganar-ganar, en realidad.

— SQLRockstar