¿Tiene sentido NO condensar las relaciones uno a uno?

Si tenemos la Tabla A que tiene una relación uno a uno con la Tabla B, ¿alguna vez tiene sentido mantenerlos separados? ¿O nunca está de más combinarlos en una sola mesa? ¿Alguno de estos escenarios (dos tablas versus una tabla combinada) impacta algo con respecto a su forma normal (1NF, 2NF, 3NF, etc.)?

Sí, hay muchas razones por las que este puede ser el mejor diseño.

Puede tener una relación de herencia / extensión, por ejemplo, puede tener una Usertabla y luego una Administratortabla que tenga 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 Administratortabla. Necesitaría algo similar si admite un flujo de trabajo, por ejemplo, una ScheduledTasktabla y una CompletedTasktabla.

Es posible que desee tener una tabla liviana para datos de uso común Usery luego una tabla más grande para detalles que no necesita con mucha frecuencia UserDetails. Esto puede mejorar el rendimiento porque podrá incluir más registros en una sola página de datos.

Es posible que desee diferentes permisos para las tablas, por ejemplo, UseryUserCredentials

Es posible que desee diferentes estrategias de copia de seguridad y, por tanto, poner dos mesas en diferentes particiones, por ejemplo, TransactionyTransactionArchive

Es posible que necesite más columnas de las que se pueden admitir en una sola tabla, por ejemplo, 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 4K o lo que sea que tenga.

Agregando a la excelente respuesta de @ john-wu otro, otra razón es cuando tienes un tipo de columna A BLOB como una imagen.

Desea tener esa columna BLOB en una tabla separada, no solo para que las consultas en la tabla de usuario sean más rápidas sino también porque podría mover la tabla que contiene el blob a un espacio de tabla diferente en un almacenamiento más barato y más lento, manteniendo los datos más consultados en el espacio de tabla principal en un almacenamiento más rápido.

Uno a uno relaciones en realidad sólo tiene sentido cuando se desea que el registro relacionado en la Tabla B a ser opcional.

A veces lo que quieres es un registro variante o una Unión etiquetada . Eso significa que tiene varias tablas que contienen información diferente, pero todas relacionadas con la Tabla A en relaciones uno a uno. Luego elige qué tabla asociar en función de un campo en 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 empresarial, dos entidades A y B, que lógicamente están separadas del punto de vista empresarial, generalmente se asignan a tablas diferentes.

Por ejemplo, cuando se realiza el modelado de negocios con medios orientados a objetos, generalmente tiene algún tipo de mapeo relacional de objetos. Puede comenzar con un modelo de objetos y derivar su modelo relacional a partir de eso. Así que imagine en su modelo de objetos que ha creado las clases A y B, que, aunque los objetos tienen una correspondencia 1: 1, deberían 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, sino que pueden representar objetos comerciales, con algún comportamiento implementado en los métodos. Y cuando asigna esas clases ahora directamente a un modelo relacional, obtiene tablas separadas A y B con relación 1: 1.

Según mi experiencia, al crear un modelo de datos OO o de negocios, esta separación lógica es mucho más típica para las relaciones 1: 1 que por razones "físicas" como el rendimiento, la seguridad individual o la partición.