Si tenemos la Tabla A que tiene una relación de uno a uno con la Tabla B, ¿alguna vez tiene sentido mantenerlos separados? ¿O nunca duele combinarlos en una sola mesa? ¿Alguno de estos escenarios (dos tablas frente a una tabla combinada) afecta algo con respecto a su forma normal (1NF, 2NF, 3NF, etc.)?
Sí, hay miles de razones por las que este puede ser el mejor diseño.
Es posible que tenga una relación de herencia / extensión, por ejemplo, puede tener una tabla User y luego una tabla Administrator que tiene más campos. Ambas tablas pueden tener una clave principal de ID de usuario (y, por lo tanto, tener una relación 1: 1) pero no todos los usuarios tendrán un registro en la tabla Administrator . Necesitaría algo similar si está soportando un flujo de trabajo, por ejemplo. una tabla ScheduledTask y una tabla CompletedTask .
Es posible que desee tener una tabla ligera para los datos de uso común User y luego una tabla más grande para los detalles que no necesita muy a menudo UserDetails . Esto puede mejorar el rendimiento porque podrá incluir más registros en una sola página de datos.
Es posible que desee permisos diferentes para las tablas, por ejemplo, User y UserCredentials
Es posible que desee diferentes estrategias de copia de seguridad y, por lo tanto, coloque dos tablas en diferentes particiones, por ejemplo, Transaction y TransactionArchive
Es posible que necesite más columnas de las que se pueden admitir en una sola tabla, p. ej. Si hay muchas columnas de texto grandes que necesita poder indexar y su plataforma de base de datos está limitada a páginas de datos de 4K o lo que sea.
Agregando a la excelente respuesta de @ john-wu otro, otra razón es cuando tienes una columna tipo BLOB como una imagen.
Desea tener esa columna BLOB en una tabla separada, no solo para que las consultas en la tabla de usuarios sean más rápidas, sino también porque podría mover la tabla que contiene el blob a un espacio de tablas diferente en un almacenamiento más barato y lento, manteniendo la mayor consulta. datos en el espacio de tabla principal en un almacenamiento más rápido.
Las relaciones uno a uno solo tienen sentido cuando quiere que el registro relacionado en la Tabla B sea optional.
A veces, lo que desea es un registro de variante o Unión etiquetada . Eso significa que tiene varias tablas que contienen información diferente, pero todas relacionadas con la Tabla A en relaciones de uno a uno. A continuación, elige qué tabla asociar basándose en un campo de la Tabla A
Por ejemplo:
type Transaction(The_Type: PaymentType := Cash) is record
Amount: Integer;
case The_Type is
when Cash =>
Discount: boolean;
when Check =>
CheckNumber: Positive;
when Credit =>
CardNumber: String(1..5);
Expiration: String(1..5);
end case;
end record;
En el modelado de negocios, dos entidades A y B, que lógicamente están separadas desde un punto de vista de negocios, generalmente se asignan a tablas diferentes.
Por ejemplo, cuando realiza un modelado de negocios con medios orientados a objetos, normalmente tiene implementado algún tipo de mapeo relacional de objetos. Podría comenzar con un modelo de objeto y derivar su modelo relacional a partir de eso. Así que imagine que en su modelo de objetos ha creado las clases A y B, que, aunque los objetos tienen una correspondencia de 1: 1, deben permanecer separados debido al principio de responsabilidad única . Tenga en cuenta que en su modelo de objetos, estas clases no son solo tablas con atributos, pueden representar objetos de negocios, con algún comportamiento implementado en los métodos. Y cuando asignas esas clases ahora directamente a un modelo relacional, obtienes las tablas separadas A y B con una relación 1: 1.
Según mi experiencia, al crear un modelo de datos de negocio u OO, esta separación lógica es mucho más típica para las relaciones 1: 1 que las razones "físicas" como el rendimiento, la seguridad individual o la partición.
Lea otras preguntas en las etiquetas database relational-database normalization