Tenho uma tabela com muitos atributos que podem ser agrupados em grupos lógicos, e assim a ideia de colocar esses atributos em tabelas separadas me parece atraente. Os grupos lógicos não representam as próprias entidades. Quando um atributo no grupo é definido, a maioria dos demais atributos desse grupo também deve ser definida (mas não todos). O tipo dos campos dos grupos geralmente são VARCHAR(15-20). Não há BLOBou TEXTcampos também.
Os grupos lógicos não representam subtipos, pois não são mutuamente exclusivos.
A entidade é solicitada mais para leitura do que para escrita. Portanto, uma mesa grande parece apropriada. Além disso, desta forma as junções são evitadas nas consultas. A parte dessa abordagem que eu não gosto é o grande número de campos anuláveis.
Procurando conselhos de especialistas.
Não há nada de errado com colunas anuláveis, mesmo muitas delas, se é isso que seu domínio de dados exige.
Por outro lado, o fato de você dizer que essas colunas podem ser agrupadas logicamente implica para mim que algo mais pode estar acontecendo.
Se eles puderem ser agrupados logicamente porque diferentes conjuntos de colunas se aplicam a diferentes conjuntos de linhas, você poderá ter uma situação de subtipo de entidade .
Por outro lado, se as colunas puderem ser agrupadas porque se aplicam em momentos diferentes, você poderá ter um problema de normalização. Por exemplo, se suas colunas forem algo como "Vendas de janeiro", "Vendas de fevereiro", etc., elas devem ser linhas em uma tabela filho.
Embora não haja nada inerentemente errado com colunas anuláveis, também não há nada de errado com a junção. É o que RDBMS faz para viver.
ATUALIZAR:
Dadas informações adicionais sobre os grupos lógicos de colunas:
Existem dois tipos de subtipagem que podem ser representados em um banco de dados usando relações 1:1. Se os grupos lógicos fossem mutuamente exclusivos, a entidade pai poderia ter o que é conhecido como um atributo de particionamento que informa qual dos subtipos é aplicável. No entanto, sem um atributo de particionamento, é possível ter zero, um ou mesmo vários subtipos aplicáveis ao mesmo tempo.
A mesma questão fundamental se aplica então ao que você faz com esta situação.
Uma boa maneira de resolver isso seria observar os grupos lógicos de colunas. As colunas no grupo lógico A são iguais às do grupo lógico B - ou são totalmente diferentes? Se forem diferentes, podem ser melhor modelados na tabela única com campos anuláveis. Se forem iguais, isso pode ser uma pista de que devem ser várias linhas filhas.
Outra pista a ser observada é se faz sentido que um grupo lógico de colunas possa ganhar vida própria e começar a atrair relacionamentos de outras tabelas. Se o grupo lógico B em breve se encontrar com vários registros filho de outra tabela, pode ser um sinal de que faz sentido promover esse grupo para sua própria tabela de estilo de subtipo.
Uma última coisa a considerar é a implementação física. Se um subgrupo lógico for preenchido de forma muito esparsa, você poderá justificar a segregação dessas colunas em outra tabela para otimizar o armazenamento físico. Esta etapa não deve ser realizada de forma proativa. Esse tipo de otimização deve ser feito quando o teste de desempenho provar que é necessário.
Se nenhuma dessas coisas for verdadeira, provavelmente é melhor deixar as colunas anuláveis na tabela original.