É melhor ter uma tabela única mais ampla ou tabelas "filhas" baseadas em processos de negócios?

O exemplo com o qual estou trabalhando é um modelo de dados de fatura, onde pode haver cerca de 30 colunas quando terminarmos de projetar. Cada linha de dados seria exclusiva para uma única fatura.

Algumas das colunas são usadas por várias partes do aplicativo (número da fatura, obviamente, totais de cobrança, etc.), mas existem algumas colunas que são usadas apenas por um único processo.

Por exemplo, temos três colunas que refletem os números de controle ( varchar(18)) usados ​​por clientes externos que devemos rastrear, mas apenas o processo de rastreamento analisa essas colunas. Os números de controle são geralmente de um para um na fatura, portanto, haveria apenas um número de controle por fatura. Existem também algumas faturas que simplesmente não terão um número de controle porque são faturas mais antigas sendo importadas de um sistema que não registrava números de controle (elas representarão cerca de 25% dos dados iniciais). Mesmo essas faturas mais antigas podem eventualmente obter um número de controle (embora provavelmente sejam antigas o suficiente para não acontecer).

Faz mais sentido pegar essas colunas e fazer uma tabela separada para elas, de uma perspectiva de modelagem de dados ou de desempenho, ou devemos apenas deixá-las na tabela Faturas? As respostas para este exemplo específico são apreciadas, mas também estou curioso sobre uma resposta mais geral, pois certamente nos depararemos com esse tipo de cenário novamente.

Com base em como li este artigo da Wikipedia , pretendo dizer particionamento vertical, pelo menos em um sentido lógico (as duas tabelas diferentes estariam no mesmo armazenamento físico neste caso).

Isso faz parte de um banco de dados OLTP.

Provavelmente 75% das linhas terão um número de controle eventualmente.