Alguma vez faz sentido NÃO condensar relacionamentos individuais?

Se temos a Tabela A que tem um relacionamento individual com a Tabela B, faz algum sentido mantê-los separados? Ou nunca é demais combiná-los em uma única mesa? Algum desses cenários (duas tabelas versus uma tabela combinada) afeta alguma coisa em relação à sua forma normal (1NF, 2NF, 3NF, etc)?

Sim, existem várias razões pelas quais esse pode ser o melhor design.

Você pode ter um relacionamento de herança / extensão, por exemplo, você pode ter uma Usertabela e, em seguida, uma Administratortabela com mais campos. Ambas as tabelas podem ter uma chave primária de ID do usuário (e, portanto, ter um relacionamento 1: 1), mas nem todos os usuários terão um registro na Administratortabela. Você precisaria de algo semelhante se estiver suportando um fluxo de trabalho, por exemplo, uma ScheduledTasktabela e uma CompletedTasktabela.

Você pode querer ter uma tabela leve para dados comumente usados Usere, em seguida, uma tabela maior para detalhes que você não precisa com muita frequência UserDetails. Isso pode melhorar o desempenho, pois você poderá ajustar mais registros em uma única página de dados.

Você pode querer permissões diferentes para as tabelas, por exemplo, UsereUserCredentials

Você pode querer estratégias de backup diferentes e, portanto, colocar duas tabelas em partições diferentes, por exemplo, TransactioneTransactionArchive

Você pode precisar de mais colunas do que as suportadas em uma única tabela, por exemplo, se houver muitas colunas de texto grandes que você precise indexar e sua plataforma de banco de dados estiver limitada a páginas de dados de 4K ou o que você quiser.

Adicionando à excelente resposta de @ john-wu outro, outro motivo é quando você tem uma coluna do tipo BLOB como uma imagem.

Você deseja que essa coluna BLOB em uma tabela separada, não apenas para consultas na tabela de usuários, seja mais rápida, mas também porque você pode mover a tabela que contém o blob para um espaço de tabela diferente em um armazenamento mais lento e barato, mantendo os dados mais consultados no diretório espaço de tabela principal em um armazenamento mais rápido.

Os relacionamentos individuais apenas fazem sentido quando você deseja que o registro relacionado na Tabela B seja opcional.

Às vezes, o que você deseja é um registro variante ou união marcada . Isso significa que você tem várias tabelas contendo informações diferentes, mas todas relacionadas à Tabela A em relacionamentos um a um. Em seguida, você escolhe qual tabela associar com base em um campo na Tabela A

Por exemplo:

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;

Na modelagem de negócios, duas entidades A e B, que são logicamente separadas do ponto de vista comercial, geralmente são mapeadas para tabelas diferentes.

Por exemplo, ao fazer modelagem de negócios com meios orientados a objetos, você normalmente tem algum tipo de mapeamento objeto-relacional. Você pode começar com um modelo de objeto e derivar seu modelo relacional. Então, imagine no seu modelo de objeto que você criou as classes A e B, que, embora os objetos tenham uma correspondência 1: 1, devem permanecer separadas por causa do princípio de responsabilidade única . Observe que no seu modelo de objeto, essas classes não são apenas tabelas com atributos, elas podem representar objetos de negócios, com algum comportamento implementado nos métodos. E quando você mapeia essas classes agora diretamente para um modelo relacional, obtém as tabelas A e B separadas com relacionamento 1: 1.

Para minha experiência, ao criar um modelo de dados de negócios ou OO, essa separação lógica é muito mais típica para relacionamentos 1: 1 do que razões "físicas", como desempenho, segurança individual ou particionamento.