Tenho uma tabela que possui 46 campos com uma AUTO_INCREMENT PRIMARY KEY. É difícil olhar para uma tabela que tem tantas colunas, então frequentemente uso uma SELECTinstrução para ver 34 dos campos que categorizo mentalmente como 'grupo 1' e 12 campos que categorizo como 'grupo 2'.
Eu enfrentaria um desempenho atingido em leituras/gravações se eu dividisse esta tabela em duas tabelas, uma com 34 campos e outra com 12 campos?
Ambos teriam a mesma CHAVE PRIMÁRIA AUTO_INCREMENT para que pudessem ser unidos na chave PRIMÁRIA se eu precisar examinar 46 campos de uma vez.
Crie uma visualização .
Se houver uma relação obrigatória de 1:1, você não agregará muito valor dividindo a tabela. Há casos em que as relações 1:0..1 são melhores como tabelas separadas.
E suas chaves ficariam fora de sincronia rapidamente. Supondo que você vá inserir nas duas tabelas em uma única transação, uma falha na primeira inserção geraria um gap que não acontece na 2ª tabela.
Se você tiver um AUTO_INCREMENT em uma tabela e usar LAST_INSERT_ID , perderá a capacidade de fazer INSERTs de várias linhas
O princípio KISS se aplica...
É difícil dar uma resposta sem saber quais são as colunas. Se a tabela for projetada corretamente (normalizada corretamente), ter muitas colunas não é uma coisa ruim. Você pode usar exibições conforme sugerido ou pode apenas selecionar as colunas que precisa ver com base no motivo pelo qual está fazendo uma consulta.
Meu palpite, porém, é que se víssemos as colunas, encontraríamos alguns casos de problemas de normalização, já que você naturalmente deseja ver apenas parte delas. Isso é apenas um palpite, não uma regra de design ou algo assim.