Os bancos de dados relacionais são projetados para armazenar muitas linhas por tabela. Existem vários mecanismos para facilitar tabelas grandes, como:

• Índices em qualquer combinação de campos para acelerar as pesquisas
• O cache de páginas para que as páginas mais usadas permaneçam na memória
• Particionamento vertical (bancos de dados colunares) para acelerar ainda mais as solicitações
• Algoritmos avançados, como hash joins e group bys (pelo menos em bancos de dados diferentes do MySQL)
• Uso de vários processadores e discos para processar consultas

Há uma coisa que é mais difícil ao colocar dados em uma única tabela, que é a segurança. E, de fato, em algumas circunstâncias esta é uma preocupação primária e basicamente requer que os dados sejam colocados em tabelas separadas. Essas aplicações são raras e distantes entre si.

Para dar um exemplo de quão ruim pode ser o armazenamento de dados em várias tabelas, imagine que em seu sistema você tenha um registro por empresa e o armazene em uma tabela. Este registro armazena informações sobre a empresa - algo como nome, endereço, o que for. A chamada é de 100 bytes de informação.

Em seu esquema, há uma tabela separada para cada "empresa", ou seja, uma linha por tabela. Esse registro residirá em uma página de dados. Uma página de dados pode ter 16 kbytes, então você está desperdiçando cerca de 15,9 kbytes para armazenar esses dados. Armazenar 1000 desses registros ocupa 16 Mbytes em vez de cerca de 7 páginas (112 Kbytes). Isso pode ser um impacto significativo no desempenho.

Além disso, com várias tabelas, você não leva em conta os desafios de manter todas as tabelas e garantir a exatidão dos dados nas diferentes tabelas. As atualizações de manutenção precisam ser aplicadas a milhares de tabelas, em vez de um punhado.