Muitas colunas versus poucas tabelas - em termos de desempenho

Sim, estou ciente de que a normalização de dados deve ser minha prioridade (como é).

1. Eu tenho uma tabela com 65 colunas de armazenamento de dados do veículo com colunas: used_vehicle, color, doors, mileage, pricee assim por diante, no total de 65.
2. Agora, eu posso dividir isso e ter uma Vehiclemesa, VehicleInterior, VehicleExterior, VehicleTechnical, VehicleExtra(todo o um-para-um com principal Vehicletabela).

Vamos supor que eu tenha cerca de 5 milhões de linhas (veículos).

Com SELECTuma WHEREcláusula: o desempenho será melhor pesquisado (ambos os casos indexados pelo menos em IDs):

1. Vehicle mesa com 65 colunas ou
2. Vehicletabela com JOINSem outras quatro tabelas (todas com 5 milhões de linhas) para retornar todos os dados relacionados a Vehicle?

(Conforme o mecanismo do banco de dados, considere o PostgreSQL e / ou MySQL).

Realmente aprecia alguma ideia detalhada que possa ter da sua experiência anterior?

Supondo que estamos falando de relacionamentos 1: 1 entre todas as tabelas.

O armazenamento geral é praticamente sempre (substancialmente) mais barato com uma única tabela em vez de várias tabelas no relacionamento 1: 1. Cada linha possui 28 bytes de sobrecarga, além de, normalmente, mais alguns bytes para preenchimento extra. E você precisa armazenar a coluna PK com todas as tabelas. E tenha um índice (redundante) separado em cada uma dessas colunas ... O tamanho importa para o desempenho.

Isso é verdade mesmo se muitas colunas forem NULL na maioria das linhas, porque o armazenamento NULL é muito barato :

• Configurando o PostgreSQL para desempenho de leitura

Ao recuperar todas as colunas, uma única tabela é substancialmente mais rápida que 5 tabelas juntas. Também é muito mais simples . Pode ser difícil associar cinco tabelas se nem todas as linhas estiverem presentes em todas as tabelas. Com as WHEREcondições direcionadas a uma única tabela, é fácil anexar outras tabelas LEFT JOIN. Não é tão trivial se você tiver predicados em várias tabelas ...

O particionamento vertical ainda pode melhorar o desempenho de determinadas consultas. Por exemplo, se 90% de suas consultas recuperarem as mesmas 5 colunas das 65 disponíveis, isso seria mais rápido com uma tabela mantendo essas 5 colunas.

• O que é recuperado do disco durante uma consulta? (minha resposta)

OTOH, você pode atender a essas consultas em algumas colunas selecionadas com um índice de "cobertura" que permite verificações apenas de índice .

Outro candidato ao particionamento vertical: se você tiver muitas atualizações em apenas algumas colunas, enquanto o resto quase nunca muda. Pode ser consideravelmente mais barato dividir linhas nesse caso, pois o Postgres grava uma nova versão de linha para cada atualização. Há exceções para grandes valores armazenados fora da linha ("TOASTed"). Mais detalhes:

• O que é recuperado do disco durante uma consulta? (Resposta de Daniel)
• Atualizar todas as colunas de outra tabela

Realmente depende da situação completa. Em caso de dúvida, siga a solução simples de ter uma única tabela, especialmente se ela retrata bem a realidade: no seu exemplo, todos esses são atributos de um carro e fazem sentido juntos.

Uma seleção em uma única tabela deve sempre ser mais rápida. Assim que você encontrar seu veículo, você já terá todos os detalhes.

No entanto, você perde a eficiência da normalização. Por exemplo, se 1 carro tivesse muitos modelos com opções diferentes.

Esta é uma referência db de todos os carros? Ou uma lista de veículos em segunda mão? Haveria muitos exemplos da mesma marca / modelo com as mesmas opções?

Edit: eu deveria qualificar minha resposta como sendo rdbms genéricos em vez de específico para o postgres Adardo a resposta detalhada de @ Erwin específica para o postgres