database design - entidad - ¿Cuándo usar relaciones de 1 a 1 entre las tablas de la base de datos?
relacion uno a uno oracle (8)
Una pregunta de diseño de DB: ¿cuándo decides usar tablas de relación de 1 a 1?
Uno de los lugares donde veo esto es, por ejemplo, cuando tiene una tabla de Usuario y Perfil de Usuario, las personas las dividen en lugar de poner todas las columnas solo en una tabla de Usuario.
Técnicamente, puedes poner todas las columnas en una tabla ya que su relación es de 1 a 1.
Sé que alguien dijo que para la tabla UserProfile, con el tiempo necesitas 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 de Perfil de Usuario, ¿es mejor para mí simplemente hacerlo en una sola tabla?
Creo que Shane D tiene una razón que es bastante válida. 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.
Entonces, 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 los datos basados en la actividad DML.
Avíseme si hay alguna solución mejor
Esta es una copia y pega directo de otra pregunta que surgió hoy en este hilo, pero aquí también se siente útil. ¿Hay alguna vez donde el uso de una relación de base de datos 1: 1 tenga sentido?
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 afiche comentó que 1: 1 no está normalizado, no estoy de acuerdo con eso en algunas situaciones, especialmente en la subtipificación. 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.
La única vez que he usado una relación de 1 a 1 es cuando quiero que pertenezca polimórficamente a múltiples 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.
La razón clásica es evitar las columnas que aceptan nulos.
Tener un valor NULL en una columna puede hacer que sea más difícil escribir SQL claro (mantenible). @ Ovid ha escrito sobre esto here , basándose en el trabajo de Chris Date .
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 ahí 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.
Recientemente, he visto uno en el que tenía una tabla, con la mayoría de los datos, y 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 columnas, es decir, espacio vacío.
Sin embargo, si estás 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.
Solo cuando los campos en la tabla UserProfile no son necesarios para todo el número de registros en la tabla de usuarios. Por ejemplo, si tiene 3,000,000 de usuarios pero solo 3,000 de ellos tienen UserProfiles, puede tener sentido dividirlos (para evitar un montón de columnas nulas).
Aunque ahora hay días en que las bases de datos son cada vez más rápidas y los costos de almacenamiento más baratos, realmente no hace mucha diferencia dividirlos por esta razón ...
Esto se ha abordado bien, pero solo agregaré una nota rápida para aclarar algo que no era obvio para mí y no se ha mencionado explícitamente. Una relación de 1 a 1 no significa que para cada registro en la tabla A haya 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.