Estoy tratando de mantener la práctica de mantener la base de datos normalizada, pero eso lleva a la necesidad de ejecutar múltiples consultas de unión. ¿Hay una degradación del rendimiento si muchas consultas usan combinaciones y tienen una llamada a una sola tabla que podría contener datos redundantes?SQL se une a una sola tabla: ¿diferencia de rendimiento?
Mantenga la base de datos normalizada HASTA que haya descubierto un cuello de botella. Entonces solo después de un perfil cuidadoso, deberías desnormalizar.
En la mayoría de los casos, tener un buen conjunto de índices de cobertura y estadísticas actualizadas resolverá la mayoría de los problemas de rendimiento y bloqueo sin desnormalización.
Usar una sola tabla podría empeorar el rendimiento si hay escrituras y lecturas negativas.
Con los índices adecuados configurados, sus uniones pueden funcionar muy rápidamente. Use el Analizador de SQL para determinar qué índices se deben crear o modificar para optimizar el rendimiento de sus consultas comunes. Asegúrese de tener un plan de mantenimiento configurado para que su base de datos se ejecute una vez a la semana (o todos los días para las tablas que cambian mucho) que actualice sus estadísticas e índices.
Normalmente se prefiere la normalización en lugar de mantener los datos en varias ubicaciones. Hay situaciones en las que insertar/actualizar no necesita ocurrir rápidamente y seleccionar la necesidad de ocurrir muy rápidamente, en cuyo caso podría estar mejor sin normalización. Aun así, no se recomienda una optimización prematura, por lo tanto, primero debe usar una estructura normalizada.
Una de las últimas hiperoptimizaciones disponibles a través de algunos de los sitios de la nube es, de hecho, utilizar una menor cantidad de tablas más amplias de capacidad limitada para la eficiencia. Hasta ahora en el futuro si necesita escalar salvajemente, esta es una forma. Pero no se considera una práctica deseable para cualquier dbms relacional (que esos no son).
Si tiene problemas de rendimiento, hay muchas cosas en las que trabajar primero, antes de cualquier tipo de desnormalización.
Dejamos la optimización de consultas en la base de datos por las mismas razones por las que dejamos la optimización del código hasta el compilador.
La mayoría de los RDBMS actuales son bastante buenos en este sentido en estos días.
Antes de que pienses que la desnormalización está "bien" en algunos casos, considera esto: normalmente no estás interesado en cada atributo. Por lo tanto, la carga de datos innecesarios fuera del disco es ineficiente (generalmente el componente menos eficiente de la base de datos). Esto puede ser mucho peor si tiene un diseño desnormalizado, con muchos datos redundantes seguidos. Peor aún si tiene que actualizar todos los datos redundantes. Puede ser mucho más eficiente cargar algunas tablas estrechas que contienen solo las columnas de interés y unirlas. De nuevo, esto depende de la base de datos, por lo que sin los perfiles no tiene idea.
Si realmente está preocupado por el rendimiento, probablemente esté hablando de problemas de escalabilidad. En este caso, es posible que desee consultar sharding, para lo cual es importante un diseño de esquema adecuado (normalizado).
Michael Jackson (no que uno) es famously believed to have said,
Eso fue probablemente antes de que existieran RDBMS, pero creo que habría extendido las Reglas para incluirlos.
Los SELECT de múltiples tablas casi siempre se necesitan con un modelo de datos normalizado; como suele ser el caso con este tipo de pregunta, la respuesta "correcta" a la "desnormalización"? la pregunta depende de varios factores.
DBMS platform.
El rendimiento relativo de las consultas de varias tablas o de una sola tabla depende de la plataforma en la que viva la aplicación: el nivel de sofisticación de los optimizadores de consultas puede variar. MySQL, por ejemplo, en mi experiencia, es increíblemente rápido en consultas de tabla única, pero no optimiza las consultas con varias combinaciones tan bien. Esto no es un problema real con tablas más pequeñas (menos de 10K filas, por ejemplo), pero realmente duele con grandes (10M +).
volumen de datos
A menos que usted está buscando en las tablas de la región fila 100K +, hay más o menos no debería ser un problema. Si miras el tamaño de las mesas en cientos de filas, ni siquiera me molestaría en pensar en la indexación.
(des) la normalización
El objetivo de la normalización es reducir al mínimo la duplicación, para tratar de asegurar que cualquier valor de campo que debe ser actualizada sólo necesita ser cambiado en un solo lugar. La desnormalización rompe eso, lo cual no es un gran problema si las actualizaciones de los datos duplicados son raras (lo ideal es que nunca ocurran). Así que pensar muy cuidadosamente antes de duplicar cualquier cosa menos los datos más estáticos, Tenga en cuenta que la base de datos puede crecer significativamente
Requerimientos/Restricciones
¿Qué requisitos de rendimiento ¿Estás tratando de satisfacer? ¿Tiene hardware fijo o un presupuesto? A veces, un aumento en el rendimiento puede lograrse con mayor facilidad, e incluso a menor costo, mediante una actualización de hardware. ¿Qué volumen de transacción esperas? Un sistema de contabilidad para pequeñas empresas tiene un perfil muy diferente al de, digamos, Twitter.
Una última idea me sorprende: si se normaliza lo suficiente, ¿cómo se diferencia su base de datos de un archivo plano? SQL es excelente para datos flexibles y retiros multidimensionales, pero puede ser un orden de magnitud (al menos) más lento que un archivo directo secuencial o simplemente indexado.
En aras de la normalización, la descomposición de tablas tiene un costo. Hay un componente de rendimiento a ese costo. El costo de rendimiento de las tablas en descomposición y la unión de datos en las consultas se puede mantener bajo: usando un buen DBMS; diseñar tablas correctamente; diseñar índices correctos; dejar que el optimizador haga su trabajo; y ajustar las características específicas del DBMS del diseño físico.
También hay un costo para componer tablas grandes que materializan las uniones. El costo en términos de anomalías de actualización y dificultades de programación se describe en buenos tutoriales sobre normalización. También hay un costo de rendimiento para componer tablas. En muchos productos DBMS, cargar una fila muy grande en la memoria cuesta más que cargar una fila más pequeña. Cuando compone tablas muy anchas, termina forzando al DBMS a leer filas muy grandes, solo para descartar la mayoría de los datos leídos en la memoria. Esto puede ralentizarte aún más de lo que lo hace la normalización.
En general, no se desnormalice al azar. Cuando sea necesario, use una disciplina de diseño que haya sido probada por personas que fueron antes que usted, incluso si esa disciplina resulta en una desnormalización. Recomiendo el esquema de estrella como tal disciplina. Tiene mucho a favor.Y todavía hay muchas situaciones en las que un diseño normalizado funciona mejor que un diseño de esquema en estrella.
Aprender más de un conjunto de principios de diseño y aprender a usar qué conjunto es la segunda etapa de aprendizaje para ser un experto.
¿Diferencia de rendimiento?
Diferencia de cordura.
gracias por la respuesta – zsharp