database - soporta - optimizar group by mysql

¿Por qué usar una relación 1-a-1 en el diseño de la base de datos? (6)

A menudo las personas hablan de una relación 1: 0..1 y la llaman 1: 1. En realidad, un RDBMS típico no puede soportar una relación literal 1: 1 en ningún caso.

Como tal, creo que es justo abordar la subclasificación aquí, aunque técnicamente requiere una relación 1: 0..1, y no el concepto literal de 1: 1.

Un 1: 0..1 es bastante útil cuando tiene campos que serían exactamente iguales entre varias entidades / tablas. Por ejemplo, los campos de información de contacto, como la dirección, el número de teléfono, el correo electrónico, etc., que pueden ser comunes tanto para los empleados como para los clientes, podrían dividirse en una entidad creada exclusivamente para información de contacto.

Una tabla de contactos tendría información común, como dirección y número (s) de teléfono.

Así que una tabla de empleados contiene información específica de los empleados, como el número de empleado, la fecha de contratación, etc. También tendría una referencia de clave externa a la tabla de contacto para la información de contacto del empleado.

Una tabla de clientes tendría información del cliente, como una dirección de correo electrónico, el nombre de su empleador y tal vez algunos datos demográficos, como el género y / o el estado civil. El cliente también tendría una referencia de clave externa a la tabla de contacto para su información de contacto.

Al hacer esto, todos los empleados tendrían un contacto, pero no todos los contactos tendrían un empleado. El mismo concepto se aplicaría a los clientes.

Me está costando mucho descubrir cuándo usar una relación 1-a-1 en el diseño de db o si alguna vez es necesario.

Si puede seleccionar solo las columnas que necesita en una consulta, siempre hay un punto para dividir una tabla en relaciones 1 a 1. Supongo que la actualización de una tabla grande tiene más impacto en el rendimiento que una tabla más pequeña y estoy seguro de que depende de cuánto se utiliza la tabla para ciertas operaciones (lectura / escritura)

Entonces, al diseñar un esquema de base de datos, ¿cómo se tienen en cuenta las relaciones 1 a 1? ¿Qué criterios utiliza para determinar si necesita uno y cuáles son los beneficios de no usar uno?

¡Gracias!

Bueno, en el papel, la forma normalizada parece ser la mejor. En el mundo real suele ser una compensación. La mayoría de los sistemas grandes que conozco hacen concesiones y no intentan ser completamente normalizados.

Trataré de dar un ejemplo. Si está en una aplicación bancaria, con una cuenta de libreta de 10 millones, y las transacciones habituales serán solo una consulta del saldo más reciente de cierta cuenta. Tiene la tabla A que almacena solo esa información (número de cuenta, saldo de cuenta y nombre del titular de la cuenta).

Su cuenta también tiene otros 40 atributos, como la dirección del cliente, el número de impuestos, la identificación para la asignación a otros sistemas que se encuentra en la tabla B.

A y B tienen mapeo uno a uno.

Para poder recuperar rápidamente el saldo de la cuenta, es posible que desee emplear una estrategia de índice diferente (como el índice hash) para la tabla pequeña que tiene el saldo de la cuenta y el nombre del titular de la cuenta.

La tabla que contiene los otros 40 atributos puede residir en diferentes espacios de tabla o almacenamiento, emplear diferentes tipos de indexación, por ejemplo, porque quiere ordenarlos por nombre, número de cuenta, ID de rama, etc. Su sistema puede tolerar la recuperación lenta de estos 40 atributos, mientras que necesita una rápida recuperación de su consulta de saldo de cuenta por número de cuenta.

Tener todos los 43 atributos en una tabla parece ser natural, y probablemente sea ''naturalmente lento'' e inaceptable solo para recuperar el saldo de una sola cuenta.

Desde el punto de vista lógico, una relación 1: 1 siempre debe fusionarse en una sola tabla.

Por otro lado, puede haber consideraciones físicas para dicha "partición vertical" o "división de filas", especialmente si sabe que accederá a algunas columnas con mayor frecuencia o en un patrón diferente a los demás, por ejemplo:

Es posible que desee cluster o partition las dos tablas de "puntos finales" de una relación 1: 1 de manera diferente.
Si su DBMS lo permite, es posible que desee colocarlos en diferentes discos físicos (por ejemplo, más crítico para el rendimiento en un SSD y el otro en un HDD barato).
Ha medido el efecto en el almacenamiento en caché y desea asegurarse de que las columnas "activas" se mantengan en caché, sin que las columnas "frías" lo contaminen ".
Necesita un comportamiento de concurrencia (como el bloqueo) que sea "más estrecho" que toda la fila. Esto es altamente específico de DBMS.
Necesita una seguridad diferente en columnas diferentes, pero su DBMS no admite permisos de nivel de columna.
Los disparadores son típicamente específicos de la tabla. Si bien teóricamente puedes tener solo una tabla y hacer que el activador ignore la "mitad incorrecta" de la fila, algunas bases de datos pueden imponer límites adicionales a lo que un activador puede y no puede hacer. Por ejemplo, Oracle no le permite modificar la llamada tabla "mutante" de un activador de nivel de fila; al tener tablas separadas, solo una de ellas puede estar mutando, por lo que aún puede modificar la otra desde su activador (pero hay otras formas de evitar eso).

Las bases de datos son muy buenas para manipular los datos, por lo que no dividiría la tabla solo por el rendimiento de la actualización, a menos que haya realizado los puntos de referencia reales en cantidades representativas de datos y haya llegado a la conclusión de que la diferencia de rendimiento realmente existe y es lo suficientemente significativa la creciente necesidad de unir).

Por otro lado, si está hablando de "1: 0 o 1" (y no de un verdadero 1: 1), esta es una pregunta completamente diferente, que merece una respuesta diferente ...

Separación de funciones y abstracción de tablas de bases de datos.

Si tengo un usuario y diseño el sistema para que cada usuario tenga una dirección, pero luego cambio el sistema, todo lo que tengo que hacer es agregar un nuevo registro a la tabla de direcciones en lugar de agregar una nueva tabla y migrar los datos. .

EDITAR

Actualmente, si quisiera tener un registro de persona y cada persona tuviera exactamente un registro de dirección, entonces podría tener una relación 1 a 1 entre una tabla de Persona y una tabla de Dirección o podría tener una tabla de Persona que también tuviera Las columnas para la dirección.

En el futuro, tal vez tomó la decisión de permitir que una persona tenga múltiples direcciones. No tendría que cambiar la estructura de su base de datos en el escenario de relación 1-a-1, solo tiene que cambiar la forma en que maneja los datos que le devuelven. Sin embargo, en la estructura de una sola tabla, tendría que crear una nueva tabla y migrar los datos de la dirección a la nueva tabla para crear una estructura de base de datos de relación de uno a varios con las mejores prácticas.

Solo algunas muestras de proyectos anteriores:

una tabla TestRequests solo puede tener un informe coincidente. Pero dependiendo de la naturaleza de la Solicitud, los campos en el Informe pueden ser totalmente diferentes.
en un proyecto bancario, una tabla de Entidades contiene varios tipos de entidades: Fondos, Propiedades de RealEstate, Compañías. La mayoría de esas Entidades tienen propiedades similares, pero los Fondos requieren aproximadamente 120 campos adicionales, mientras que representan solo el 5% de los registros.

Tiene sentido usar relaciones 1-1 para modelar una entidad en el mundo real. De esa manera, cuando se agregan más entidades a su "mundo", solo tienen que relacionarse con los datos a los que pertenecen (y no más).

Esa es la clave realmente, sus datos (cada tabla) deben contener solo datos suficientes para describir lo que representa el mundo real y nada más. No debe haber campos redundantes, ya que todos tienen sentido en términos de esa "cosa". Esto significa que se repiten menos datos en todo el sistema (¡con los problemas de actualización que traerían!) Y que puede recuperar datos individuales de forma independiente (por ejemplo, no es necesario dividir / analizar cadenas).

Para averiguar cómo hacer esto, debe buscar "Normalización de la base de datos" (o Normalización), "Forma normal" y "Primera, segunda y tercera forma normal". Esto describe cómo desglosar sus datos. Una versión con un ejemplo siempre es útil. Tal vez intente este tutorial .