Cuándo usar relaciones de 1 a 1 entre las tablas de la base de datos?

Question

Pregunta de diseño de DB: ¿cuándo decide utilizar tablas de relación de 1 a 1?

Uno de los lugares en los que veo esto es, por ejemplo, cuando tiene una tabla User y UserProfile, las personas las dividen en lugar de poner todas las columnas solo en una tabla User.

Técnicamente, puede simplemente poner todas las columnas en una tabla ya que su relación es 1-a-1.

Sé que alguien dijo que para la tabla UserProfile, con el tiempo tiene que modificar la tabla para agregar más columnas, pero realmente no creo que este sea un buen motivo para dividir las tablas.

Entonces, si voy a diseñar una tabla de usuario y una tabla UserProfile, ¿es mejor para mí simplemente hacerlo en una sola tabla?

Answer 1

La única vez que he usado una relación de 1 a 1 es cuando quiero que pertenezca polimórficamente a varios objetos.

Como una dirección, por ejemplo. Un usuario tiene una dirección, una empresa tiene una dirección, un restaurante destacado tiene una dirección. Todas las instancias se manejan en la misma tabla y tienen el mismo código que la rige. Piense en ello como refactorizar su modelo de datos para poder reutilizarlo en otros lugares.

Answer 2

Solo cuando los campos de la tabla UserProfile no son necesarios para todos los registros de la tabla de usuarios. Por ejemplo, si tenía 3.000.000 de usuarios, pero solo 3.000 de ellos tienen UserProfiles, puede que tenga sentido dividirlos (para evitar un montón de columnas nulas).

Aunque ahora hay una gran cantidad de bases de datos con mayor velocidad y costos económicos de almacenamiento, realmente no hace mucha diferencia dividirlos por esta razón ...

Answer 3

Piense en cómo diseñaría los objetos comerciales. ¿Va a tener un objeto de usuario con 50 propiedades, o va a tener un objeto de usuario con algunas propiedades de detalle y luego un objeto de perfil que contiene otros datos para un perfil?

Debe usar 1-a-1 cuando los datos en la tabla están relacionados, pero no están para el mismo propósito. (probablemente podría estar mejor redactado)

También puede hacer las cosas más fáciles de encontrar. No hay muchas cosas que odio más que tener que mirar a través de una mesa con 75 columnas.

Answer 4

He visto recientemente uno donde tenía una tabla, con la mayoría de los datos, y luego otra tabla con muchos datos opcionales.

La segunda tabla tenía un tercio de las filas, pero tres veces más columnas.

Esto se hizo hace unos años evitar muchos nulos en las columnas, es decir, espacio vacío.

Sin embargo, si está haciendo esto ahora, me gustaría no molestarme. Vive con el espacio vacío La molestia que puede causar el desarrollo de aplicaciones simplemente no lo vale, y el espacio es más barato que el tiempo de desarrollo.

Answer 5

El motivo clásico es evitar las columnas que aceptan nulos.

Tener un valor NULL en una columna puede dificultar la escritura de SQL claro (mantenible). @Ovid ha escrito sobre este here, basándose en el trabajo de Chris Date.

Answer 6

Esto es una copia y pegado directo de otra pregunta que surgió hoy en este hilo, pero también se siente útil aquí. Is there ever a time where using a database 1:1 relationship makes sense?

Los uso principalmente por algunas razones. Uno es cambios significativos en la tasa de cambio de datos. Algunas de mis tablas pueden tener pistas de auditoría donde rastrear versiones anteriores de registros, si solo me importa rastrear versiones anteriores de 5 de 10 columnas dividir esas 5 columnas en una tabla separada con un mecanismo de seguimiento de auditoría es más eficiente. Además, puedo tener registros (por ejemplo, para una aplicación de contabilidad) que solo son de escritura. No puede cambiar los montos en dólares o la cuenta para la que estaban, si cometió un error, entonces necesita hacer un registro correspondiente para ajustar el registro incorrecto y luego crear una entrada de corrección. Tengo restricciones en la tabla que imponen el hecho de que no pueden ser actualizadas o eliminadas, pero puedo tener un par de atributos para ese objeto que son maleables, que se guardan en una tabla separada sin la restricción de la modificación. Otra vez que hago esto es en aplicaciones de registros médicos. Hay datos relacionados con una visita que no pueden modificarse una vez que se inicia sesión, y otros datos relacionados con una visita que se pueden cambiar después del cierre de sesión. En ese caso, dividiré los datos y pondré un disparador en la mesa bloqueada que rechace las actualizaciones de la tabla bloqueada cuando se cierre la sesión, pero permitiendo actualizaciones a los datos que el médico no está desactualizando.

Otro cartel comentó que 1: 1 no está normalizado, no estoy de acuerdo con eso en algunas situaciones, especialmente en el subtipado. Digamos que tengo una tabla de empleados y la clave principal es su SSN (es un ejemplo, vamos a guardar el debate sobre si esta es una buena clave o no para otro hilo). Los empleados pueden ser de diferentes tipos, por ejemplo temporales o permanentes, y si son permanentes, tienen más campos para completar, como el número de teléfono de la oficina, que no debería ser nulo si el tipo = 'Permanente'. En una tercera base de datos de forma normal, la columna debe depender solo de la clave, es decir, del empleado, pero en realidad depende del empleado y del tipo, por lo que una relación 1: 1 es perfectamente normal y deseable en este caso. También evita tablas demasiado dispersas, si tengo 10 columnas que normalmente están llenas, pero 20 columnas adicionales solo para ciertos tipos.

Answer 7

Creo que Shane D tiene un motivo que es bastante válido. Como incluso me encontré con la misma situación para una tabla que tiene alrededor de 40 columnas, los datos de estas columnas se cargan a través de csvs y se usan solo para informes y un conjunto de columnas para procesar esos archivos, que frecuentemente se actualizan.

Por lo tanto, si mantenemos una tabla como solución. Realizamos actualizaciones frecuentes en esa tabla y actualizaremos solo 5 columnas de 50. Siento que cada actualización altera la asignación de filas y hay una gran posibilidad de encadenamiento de filas, así que para evitar el encadenamiento de filas, seguí el enfoque de separar datos basado en la actividad DML.

Avísame si alguna solución mejor

Answer 8

Esto ha sido bien tratado, pero sólo voy a poner una nota rápida para aclarar algo que no era obvio para mí y no se ha indicado explícitamente. Una relación 1 a 1 no significa que para cada registro en la tabla A hay 1 registro correspondiente en la tabla B. En cambio, significa que para cada registro en la tabla A habrá 0 o 1 registros correspondientes en la tabla B.

Shane D. y otros describen escenarios que aprovechan este hecho.