Você está lutando com o particionamento vertical. Esta é uma técnica de design de banco de dados físico para melhorar o desempenho. Como em qualquer técnica de design de banco de dados físico, sua aplicabilidade depende das consultas específicas que você está tentando otimizar e se essa técnica as otimizará. Do ponto de vista lógico, se esses novos campos dependem da chave candidata para sua entidade, são fatos sobre ela que pertencem a ela. Primeiro, certifique-se de entender completamente a dependência funcional desses novos campos nas suas chaves candidatas para verificar se realmente são fatos sobre as visualizações de página diárias. Se estiverem, decidir particioná-las em outra tabela é uma otimização de desempenho que só deve ser feita se atingir seus objetivos de desempenho.
Em geral, o particionamento vertical é útil se você consultar essas novas colunas com pouca frequência e distinta das outras colunas na tabela original. Ao colocar essas colunas em outra tabela que compartilha a mesma PK da tabela existente, você pode consultá-la diretamente quando desejar essas novas colunas e obter muito mais rendimento, pois você terá muito mais linhas por página em disco para esta nova tabela como todas as colunas da tabela original não estarão nessas linhas. No entanto, se você sempre consultar essas colunas junto com as colunas da tabela original, uma partição vertical não faria muito sentido, pois você sempre precisará da junção externa para obtê-las. As páginas das tabelas no disco entram no buffer pool de um DBMS de forma independente, nunca pré-ingressadas, e, portanto, essa associação terá que ocorrer com cada execução de consulta, mesmo que os dados sejam fixados no buffer pool. Nesse cenário, torná-las NULLABLE colunas na tabela original permitiria ao mecanismo de armazenamento DBMS armazená-las eficientemente quando NULL e eliminaria a necessidade de ingressar na recuperação.
Parece-me que o seu caso de uso é o último e adicioná-los como NULLABLE à sua tabela original é o caminho a seguir. Mas, como acontece com todo o resto no design do banco de dados, isso depende e, para tomar a decisão certa, você precisa conhecer a carga de trabalho esperada e do que depende uma boa escolha. Um bom exemplo de um caso de uso adequado para o particionamento vertical seria um painel de pesquisa de pessoas, em que seu aplicativo tem informações muito raramente preenchidas sobre uma pessoa em que alguém pode querer pesquisar, mas raramente o faz. Se você colocar essas informações em uma tabela diferente, terá algumas boas opções de desempenho. Você pode escrever a pesquisa para ter 2 consultas - uma que use as informações principais, sempre preenchidas, para pesquisar apenas (como sobrenome ou ssn), e aquele que une as informações muito raramente preenchidas com frequência apenas quando solicitadas para pesquisa. Ou você pode tirar proveito do otimizador DBMS se for inteligente o suficiente para reconhecer, para um determinado conjunto de variáveis do host, que a junção externa não é necessária e não a executará, e, portanto, você só precisa criar 1 consulta.
Qual plataforma DBMS você está usando? A maneira pela qual a plataforma lida com o armazenamento de coluna NULL otimiza sua consulta, bem como a disponibilidade de suporte a colunas esparsas (o SQL Server possui isso) afetará a decisão. Por fim, eu recomendaria experimentar os dois projetos em um ambiente de teste com dados e carga de trabalho com tamanho de produção e ver quais alcançam melhor seus objetivos de desempenho.