¿Cuáles son las ventajas de utilizar una relación de tabla uno a uno? (MySQL)

Question

¿Cuáles son las ventajas de utilizar una relación de tabla uno a uno en lugar de simplemente almacenar todos los datos en una tabla? Entiendo y uso de uno a muchos, muchos a uno y muchos a muchos todo el tiempo, pero implementar una relación de uno a uno parece una tarea tediosa e innecesaria, especialmente si usa nombres. convenciones para relacionar objetos (php) con tablas de bases de datos.

No pude encontrar nada en la red o en este sitio que pudiera proporcionar un buen ejemplo real de una relación uno a uno. Al principio, pensé que podría ser lógico separar los "usuarios", por ejemplo, en dos tablas, una que contenga información pública, como un "sobre mí" para páginas de perfil y otra que contenga información privada, como inicio de sesión/contraseña, etc. Pero ¿por qué? a pesar de todas las molestias de usar UNIONES ÚNICAS innecesarias cuando puede simplemente elegir qué campos seleccionar de esa tabla de todos modos? Si estoy mostrando la página del perfil del usuario, obviamente solo SELECCIONARía id, username, email, aboutme, etc. y no los campos que contienen su información privada.

¿Alguien me quiere aclarar con algunos ejemplos del mundo real de relaciones uno-a-uno?

Answer 1

He usado la relación de uno a uno para extender algunas funciones en las aplicaciones existentes, sin afectar la estructura de la base de datos de la aplicación. Esta es una forma discreta de que extiende las tablas db existentes.

Otra razón para usar uno-a-uno es para la implementación de Herencia de tablas Clase, en el que cada clase en la jerarquía tiene una mesa, y un objeto tiene una fila correspondiente en su clase de mesa, en su clase padre mesa, en su mesa de abuelos, etc.

Véase, por ejemplo, Doctrina 2 Class Table Inheritance Page

Answer 2

Un posible uso es cuando parte de la información es opcional. De esta forma, no necesita tener un grupo de campos con valores nulos en una tabla grande, sino que puede separarlos lógicamente en la tabla obligatoria y una tabla opcional.

Otro uso es cuando algunos de los datos se comparten con tablas diferentes. Por ejemplo, digamos que tiene un sitio donde vende partes de computadoras. Puede poner los detalles que todos los componentes comparten en, por ejemplo. tabla de "partes", pero pon los detalles en "motherboards", "cpus", etc. que simplemente usarían la tabla de partes con una relación de uno a uno.

Answer 3

El motor de la base de datos puede tener que cargar filas enteras en la memoria para extraer datos de ellas, incluso si solo se está leyendo un subconjunto de campos. Menos campos por fila significa más filas por página, lo que significa menos accesos al disco.

Answer 4

Aquí hay dos, estoy seguro de que otros se publicará más

• desea extender una tabla existente sin tener que modificar la tabla. Tal vez fue suministrado por un proveedor externo y desea mantener sus extensiones separadas simplemente por tener una segunda tabla que comparte la misma clave.
• tal vez hay columnas de ancho fijo en la tabla a las que se accede con frecuencia, y variables que no lo son. En este caso, puede haber ganancias de eficiencia al tener una tabla con una longitud de fila fija para las cosas frecuentes, con una tabla secundaria para todo lo demás.

Además, cuando la normalización de una base de datos, dicen a 3rd Normal Form (3NF) que puede encontrar usted tiene columnas que no son realmente "sobre" la llave y necesitan ser retirado a una tabla separada.

Answer 5

Hemos utilizado "relación uno a uno" cuando necesitábamos extender una de nuestras tablas con too many fields (96 campos); entonces, creamos otra tabla y ponemos cada campo nuevo dentro de ella.

De todos modos, un enfoque que me gusta es:

Table_Base: 
    ID 
    MANDATORY_FIELD 
Table_Option: 
    ID 
    OPTIONAL_FIELD 

Answer 6

específicamente para su ejemplo: Usted no quiere que la información del usuario, como el nombre y la dirección almacenada en la misma tabla que la información de acceso y la contraseña, ya que este forma en que puede otorgar permiso a alguien de su organización en la tabla de información de usuario, y no en la tabla de datos de inicio de sesión.No estoy de acuerdo con los demás en el tema "demasiados campos para una mesa". Si hay muchos campos, y no los necesita todos en su formulario o informe, puede seleccionar solo los campos que necesita con sql, o incluso utilizar una vista para asegurarse de que no obtenga demasiados datos.

Answer 7

En OO tiene herencia. Por lo tanto, podría tener una tabla que contenga los datos del objeto principal y otras tablas que contengan campos específicos para los niños.

Answer 8

razón más común es que la relación puede ser no obligatoria. es decir, existe un conjunto de atributos aplicables a cada entidad base pero algunos atributos que solo se aplican a un subconjunto.

Otra razón válida para hacerlo es controlar los derechos de acceso; puede tener una tabla de clientes utilizada en toda la aplicación y aunque cada cliente tenga una contraseña y tarjeta de crédito, puede restringir los privilegios de visibilidad/actualización.

Comentario de Marga Keuvelaar sobre Ignacio Vazquez-Abrams la respuesta es incorrecta. Es posible que pueda aliviar el impacto utilizando un mejor DML/DDL, pero no en todos los casos. Sin embargo, está negociando la transparencia del modelo de datos con los beneficios de rendimiento, que siempre deben considerarse cuidadosamente.

C.

Answer 9

Además de lo que ya se ha dicho,

algunas columnas pueden tener diferentes requisitos de "autorización de seguridad" que otros. P.ej. el nombre de un empleado puede ser "un poco más público" que su salario. Ahora, el DBMS no aplica normalmente la seguridad de nivel de columna, pero la seguridad a nivel de tabla a menudo lo es.

Por lo tanto, al señalar el salario en una tabla separada, usted se compra la posibilidad de implementar los requisitos de seguridad del usuario utilizando solo las instalaciones de seguridad del DBMS.

Answer 10

Una cosa más, basado en mi experiencia que no se ha mencionado:

La separación en dos tablas también ayuda en la creación de las clases del modelo. Digamos que tiene una tabla Customers y una tabla DriverLicense y una relación uno a uno entre ellos. Si usa el marco de entidad, apuesto a que debería ser mejor si tiene dos tablas separadas, ya que puede tener dos clases de modelo en su aplicación, Clase de cliente y Licencia de conductor. De esta forma, el marco de entidad hará que sea muy fácil agregar una nueva información de Licencia de Conducir más tarde a un cliente existente, o eliminarla y actualizarla. Brevemente, considerando también el lado del Desarrollo Web, creo que si son dos entidades distintas, deberían tener sus propias tablas, incluso si tienen una relación de uno a uno.