database - relacional - relacion 1 a 1 mysql
¿Cuándo debería usar una relación uno a uno? (12)
1 a 0..1
El "1 a 0..1" entre las superclases y las subclases se usa como parte de la estrategia "todas las clases en tablas separadas" para implementar la herencia .
Un "1 a 0..1" se puede representar en una sola tabla con una porción "0..1" cubierta por campos con capacidad NULL. Sin embargo, si la relación es principalmente "1 a 0" con solo unas pocas filas "1 a 1", dividir la porción "0..1" en una tabla separada podría ahorrar algunos beneficios de almacenamiento (y rendimiento de caché). Algunas bases de datos son más ingeniosas para almacenar NULL que otras, por lo que un "punto de corte" donde esta estrategia sea viable puede variar considerablemente.
1 a 1
El real "1 a 1" divide verticalmente los datos, lo que puede tener implicaciones para el almacenamiento en caché. Las bases de datos generalmente implementan cachés en el nivel de página, no en el nivel de campos individuales, por lo que incluso si selecciona solo unos pocos campos de una fila, normalmente se almacenará en caché toda la página a la que pertenece esa fila. Si una fila es muy amplia y los campos seleccionados son relativamente angostos, terminará almacenando mucha información que realmente no necesita. En una situación como esa, puede ser útil dividir verticalmente los datos, de modo que solo la parte o las filas más estrechas y utilizadas con más frecuencia se almacenen en caché, para que más de ellas puedan caber en la memoria caché, haciendo que la memoria caché sea efectivamente "más grande".
Otro uso de la partición vertical es cambiar el comportamiento de bloqueo: las bases de datos normalmente no se pueden bloquear en el nivel de los campos individuales, solo en las filas completas. Al dividir la fila, está permitiendo que se produzca un bloqueo en solo una de sus mitades.
Los desencadenantes también son típicamente específicos de la tabla. Aunque teóricamente puede tener solo una tabla y hacer que el desencadenador 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 que lo haga poco práctico. Por ejemplo, Oracle no le permite modificar la tabla de mutación: al tener tablas separadas, solo una de ellas puede estar mutando, por lo que aún puede modificar la otra desde su desencadenante.
Las tablas separadas pueden permitir una seguridad más granular.
Estas consideraciones son irrelevantes en la mayoría de los casos, por lo que en la mayoría de los casos debe considerar fusionar las tablas "1 a 1" en una sola tabla.
Perdón por esa pregunta de novato, pero ¿hay alguna necesidad real de usar una relación de uno a uno con las tablas en su base de datos? Puede implementar todos los campos necesarios dentro de una tabla. Incluso si los datos se vuelven muy grandes, puede enumerar los nombres de columna que necesita en la instrucción SELECT en lugar de usar SELECT * . ¿Cuándo realmente necesitas esta separación?
Al igual que con todas las preguntas de diseño, la respuesta es "depende".
Hay algunas consideraciones:
¿Qué tan grande será la tabla (tanto en términos de campos y filas)? Puede ser inconveniente alojar el nombre de usuario, la contraseña y otros datos menos utilizados, tanto desde el punto de vista del mantenimiento como de la programación.
los campos en la tabla combinada que tienen restricciones pueden volverse engorrosos de administrar con el tiempo. por ejemplo, si un disparador necesita disparar para un campo específico, eso sucederá para cada actualización de la tabla, independientemente de si ese campo se vio afectado.
¿Cuán seguro eres de que la relación será de 1: 1? Como lo señala This pregunta, las cosas se complican rápidamente.
El momento más sensato para usar esto sería si hubiera dos conceptos separados que solo se relacionarían de esta manera. Por ejemplo, un automóvil solo puede tener un conductor actual, y el conductor solo puede conducir un automóvil a la vez, por lo que la relación entre los conceptos de automóvil y conductor sería de 1 a 1. Acepto que este es un ejemplo inventado para demostrar el punto.
Otra razón es que desea especializar un concepto de diferentes maneras. Si tiene una tabla de Personas y desea agregar el concepto de diferentes tipos de Persona, como Empleado, Cliente, Accionista, cada uno de ellos necesitaría diferentes conjuntos de datos. Los datos que son similares entre ellos estarían en la tabla Persona, la información especializada estaría en las tablas específicas para Cliente, Accionista, Empleado.
Algunos motores de base de datos tienen dificultades para agregar una nueva columna a una tabla muy grande (muchas filas) y he visto que las tablas de extensión solían contener la nueva columna, en lugar de agregar la nueva columna a la tabla original. Este es uno de los usos más sospechosos de tablas adicionales.
También puede optar por dividir los datos de un concepto único entre dos tablas diferentes por cuestiones de rendimiento o legibilidad, pero este es un caso razonablemente especial si está empezando desde cero: estos problemas se mostrarán posteriormente.
En mi tiempo de programación, me encontré con esto solo en una situación. Que es cuando hay una relación 1-a-muchos y 1-a-1 entre las mismas 2 entidades ("Entidad A" y "Entidad B").
Cuando "Entidad A" tiene múltiples "Entidades B" y "Entidades B" tiene solo 1 "Entidad A" y "Entidad A" tiene solo 1 "Entidad B" actual y "Entidad B" tiene solo 1 "Entidad A".
Por ejemplo, un automóvil solo puede tener un conductor actual, y el conductor solo puede conducir un automóvil a la vez, por lo que la relación entre los conceptos de automóvil y conductor sería de 1 a 1. - Tomé prestado este ejemplo de la respuesta de @Steve Fenton
Donde un conductor puede conducir varios autos, simplemente no al mismo tiempo. Entonces, las entidades de Car y Driver son de 1 a muchos o de muchos a muchos. Pero si necesitamos saber quién es el controlador actual, entonces también necesitamos la relación de 1 a 1.
Mis 2 centavos.
Trabajo en un lugar donde todos desarrollamos en una gran aplicación, y todo es un módulo. Por ejemplo, tenemos una tabla de users , y tenemos un módulo que agrega detalles de Facebook para un usuario, otro módulo que agrega detalles de Twitter a un usuario. Podríamos decidir desconectar uno de esos módulos y eliminar toda su funcionalidad de nuestra aplicación. En este caso, cada módulo agrega su propia tabla con relaciones 1: 1 a la tabla de users globales, así:
create table users ( id int primary key, ...);
create table users_fbdata ( id int primary key, ..., constraint users foreighn key ...)
create table users_twdata ( id int primary key, ..., constraint users foreighn key ...)
Normalmente encuentro dos tipos generales de relación 1: 1 en la práctica:
Relaciones IS-A, también conocidas como relaciones de supertipo / subtipo. Esto ocurre cuando un tipo de entidad es realmente un tipo de otra entidad (EntityA IS A EntityB). Ejemplos:
- Persona física, con entidades separadas para Contador, Ingeniero, Vendedor, dentro de la misma empresa.
- Elemento de entidad, con entidades separadas para Widget, RawMaterial, FinishedGood, etc.
- Auto entidad, con entidades separadas para Truck, Sedan, etc.
En todas estas situaciones, la entidad del supertipo (por ejemplo, Persona, Artículo o Coche) tendría los atributos comunes a todos los subtipos, y las entidades del subtipo tendrían atributos únicos para cada subtipo. La clave principal del subtipo sería la misma que la del supertipo.
Relaciones "Jefe". Esto ocurre cuando una persona es el único jefe o gerente o supervisor de una unidad organizativa (departamento, empresa, etc.). Cuando solo se permite un jefe para una unidad organizativa, existe una relación 1: 1 entre la entidad física que representa al jefe y la entidad de la unidad organizativa.
Otro caso de uso puede ser el siguiente: puede importar datos de alguna fuente y actualizarlos diariamente, por ejemplo, información sobre libros. Luego, agrega datos sobre algunos libros. Entonces tiene sentido poner los datos importados en otra tabla que sus propios datos.
Primero, creo que se trata de modelar y definir qué consiste una entidad separada. Supongamos que tiene customers con una y solo una sola address . Por supuesto, puede implementar todo en un único customer mesa, pero si, en el futuro, le permite tener 2 o más direcciones, tendrá que refactorizar eso (no es un problema, sino tomar una decisión consciente).
También puedo pensar en un caso interesante que no se menciona en otras respuestas donde la división de la tabla podría ser útil:
Imagine, nuevamente, que tiene customers con una sola address cada uno, pero esta vez es opcional tener una dirección. Por supuesto, podría implementarlo como un grupo de columnas NULL -able como ZIP,state,street . Pero supongamos que dado que tiene una dirección, el estado no es opcional, pero sí el ZIP. ¿Cómo modelar eso en una sola tabla? Puede usar una restricción en la tabla de customer , pero es mucho más fácil dividirla en otra tabla y hacer que la clave_externa sea NULLable. De esta manera, su modelo es mucho más explícito al decir que la address la entidad es opcional, y que el ZIP es un atributo opcional de esa entidad.
Si coloca dos tablas uno a uno en una, es probable que tenga un problema de semántica. Por ejemplo, si cada dispositivo tiene un control remoto, no parece muy bueno colocar el dispositivo y el control remoto con su conjunto de características en una sola tabla. Incluso puede que tenga que perder tiempo averiguando si un determinado atributo pertenece al dispositivo o al control remoto.
Puede haber casos en que la mitad de las columnas permanezcan vacías por un tiempo prolongado o no se rellenen nunca. Por ejemplo, un automóvil podría tener un remolque con muchas características o no tenerlo. Entonces tendrás muchos atributos sin usar.
Si su tabla tiene 20 atributos, y solo 4 de ellos se usan ocasionalmente, tiene sentido dividir la tabla en 2 tablas por problemas de rendimiento.
En tales casos, no es bueno tener todo en una sola mesa. ¡Además, no es fácil lidiar con una mesa que tiene 45 columnas!
Si los datos en una tabla están relacionados, pero no pertenecen a la entidad descrita por la otra, entonces es un candidato para mantenerlo separado.
Esto podría proporcionar ventajas en el futuro, si los datos separados deben estar relacionados con alguna otra entidad, también.
Te refieres a la normalización de la base de datos. Un ejemplo en el que puedo pensar en una aplicación que mantengo es Artículos. La aplicación permite al usuario vender muchos tipos diferentes de artículos (es decir, artículos de inventario, artículos sin inventario, artículos de servicio, etc.). Si bien podría almacenar todos los campos requeridos por cada elemento en una tabla de Artículos, es mucho más fácil de mantener para tener una tabla de Artículo base que contenga campos comunes a todos los artículos y luego tablas separadas para cada tipo de artículo (es decir, Inventario, No Inventario, etc.) que contienen campos específicos solo para ese tipo de elemento. Entonces, la tabla de elementos tendrá una clave externa para el tipo de elemento específico que representa. La relación entre las tablas de elementos específicos y la tabla de elementos base sería uno a uno.
A continuación, hay un artículo sobre la normalización.
no muy seguido.
puede encontrar algún beneficio si necesita implementar cierta seguridad, por lo que algunos usuarios pueden ver algunas de las columnas (tabla 1) pero no otras (tabla 2).
Por supuesto, algunas bases de datos (Oracle) le permiten hacer este tipo de seguridad en la misma tabla, pero otras no.