¿Se normaliza la relación uno a uno?

Considere que tenemos un gran conjunto de datos estadísticos para un registro; Por ejemplo, 20-30 INTcolumnas. ¿Es mejor mantener todo el conjunto en una tabla, ya que todos pertenecen a un registro O crear otra tabla conectada con una relación uno a uno?

La ventaja de la primera es evitar JOINy tener un acceso rápido a todos los datos estadísticos para el registro correspondiente.

La ventaja de este último es mantener la columna ordenada. La primera columna es de lectura intensiva y la segunda de escritura intensiva. Por supuesto, creo que no tiene un efecto significativo en el rendimiento, ya que uso InnoDB con bloqueo de nivel de fila.

En general, quiero saber si es práctico útil separar diferentes conjuntos de datos para un solo registro.

Si se ajusta a las reglas de normalización, entonces las relaciones 1: 1 pueden normalizarse (¡por definición!). En otras palabras, no hay nada acerca de las relaciones 1: 1 que les haga imposible obedecer las formas normales.

Para responder a su pregunta sobre la practicidad de las relaciones 1: 1, hay momentos en que esta es una construcción perfectamente útil, como cuando tiene subtipos con predicados (columnas) distintos.

Las razones por las que usaría relaciones 1: 1 dependen de su punto de vista. Los DBA tienden a pensar que todo es una decisión de desempeño. Los modeladores y programadores de datos tienden a pensar que estas decisiones están orientadas al diseño o al modelo. De hecho, hay una gran superposición entre estos puntos de vista. Depende de cuáles sean sus perspectivas y prioridades. Aquí hay algunos ejemplos de motivaciones para las relaciones 1: 1:

• Tiene un subconjunto de columnas que son muy anchas y desea segregarlas físicamente en su almacenamiento por razones de rendimiento.

• Tiene un subconjunto de columnas que no se leen o actualizan con frecuencia y desea mantenerlas separadas de las columnas de uso frecuente por razones de rendimiento.

• Tiene algunas columnas que son opcionales en general, pero son obligatorias cuando sabe que el registro es de cierto tipo.

• Tiene algunas columnas que lógicamente pertenecen juntas para un subtipo y desea modelarlas para que se ajusten bien al modelo de objetos de su código.

• Tiene algunas columnas que solo pueden aplicarse a algunos subtipos de un supertipo de entidad, y desea que su esquema imponga la ausencia de estos datos para otros subtipos.

• Tiene algunas columnas que pertenecen a una entidad pero necesita proteger estas columnas en particular utilizando reglas de acceso más restrictivas (por ejemplo, salario en una tabla de empleados).

Como puede ver, a veces el controlador es el rendimiento, a veces es la pureza del modelo, o simplemente el deseo de aprovechar al máximo las reglas de esquema declarativo.

Las razones principales por las que usaría una asignación uno a uno para dividir una tabla grande en dos son, por ejemplo, razones de rendimiento:

a) La tabla tiene datos binarios / clob / blob en una tabla a la que se accede con frecuencia, por lo tanto, ralentiza el rendimiento ya que las columnas grandes se manejan de manera diferente.

b) La tabla tiene muchas columnas a las que se accede mediante diferentes consultas, por lo tanto, el rendimiento se degrada, por lo tanto, movería las columnas relacionadas a una tabla separada para mejorar el rendimiento del acceso

Sin embargo, tener muchas columnas enteras no justifica el esfuerzo adicional de dividir la tabla en tablas separadas y tener que consultarlas.