Pode ser uma boa ideia criar uma nova tabela para cada cliente de um aplicativo da web?

Isso é semi-hipotético e, como não tenho experiência em lidar com tabelas de banco de dados massivas, não faço ideia se isso é horrível por algum motivo. Para a situação:

Imagine um aplicativo baseado na Web - digamos, software de contabilidade - que possui 20.000 clientes e cada cliente possui mais de 1000 entradas em uma tabela. São 20 milhões de linhas que eu sei que certamente podem retardar consultas complexas.

Em um caso como esse, faz mais sentido criar uma nova tabela no banco de dados para cada cliente? Como os bancos de dados reagem a ter tabelas de 20k (ou mais!)?

De um modo geral, não, não faz sentido ter uma tabela (acho que você realmente quer dizer banco de dados aqui) por cliente. 20 milhões de linhas são relativamente pequenas para uma tabela de banco de dados. A velocidade da consulta nesse caso não deve ser um problema, desde que o banco de dados esteja ajustado corretamente (indexado) e as consultas sejam reunidas corretamente. Qualquer que seja o benefício que você acha que obteria separá-los, seria compensado pela complexidade adicional de gerenciar 20.000 bancos de dados individuais. Por exemplo, o que acontece quando você deseja alterar a estrutura da tabela? Agora você tem que fazer isso 20.000 vezes!

Pior ainda, se você achar que o tamanho do banco de dados está se tornando um problema, sempre poderá dividi-los em bancos de dados separados posteriormente.

Parece uma má ideia.

Não tente enganar o banco de dados com construções exóticas como essa. Os mecanismos de banco de dados são projetados com muitas otimizações para lidar com grandes conjuntos de dados. Por exemplo, o que você está descrevendo parece muito próximo de uma tentativa de implementar índices manualmente. Basta usar índices fornecidos pelo DB Engine, eles são implementados muito melhor do que você provavelmente conseguirá fazer por conta própria e não exigirá tanta manutenção.

Além disso, como regra geral. Sugiro não arquitetar um banco de dados de uma maneira que exija manipulação ou criação de estruturas de banco de dados (tabelas, campos) durante o uso normal do aplicativo. Isso torna a otimização do desempenho um problema e muitas vezes obriga a conceder muitas permissões aos usuários para realizar tarefas rotineiras, potencialmente criando brechas na segurança.

Aqui está um artigo que eu sempre aconselho as pessoas a lerem quando fazem esta pergunta:

http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html

IMHO uma única tabela não deve ser um problema, por isso não crie um problema em que ainda não exista. Há muito o que você pode fazer para ajudar no desempenho. Você pode particionar uma única tabela em vários arquivos com base no ID do cliente ou em um campo de data para ajudar no IO. Seu banco de dados não precisa acompanhar, otimizar e armazenar em cache 20.000 instruções sql diferentes para todas as consultas necessárias no site. Você pode indexar por clientid. Os clientes de 20K podem pagar por muito hardware.

Para esse tipo de tabela, um dB do tipo NoSQL pode ser usado.

Com clientes de 20 mil, o banco de dados pode não ser o seu elo mais fraco; então, por que introduzir tanta complexidade?

Essa é uma péssima abordagem.

Particione a tabela verticalmente, 2 servidores de banco de dados, um para IDs de usuário ímpares e outro para par, deve funcionar bem (os dados não estão relacionados entre os usuários).

Classifique os dados por user_id e, se isso não for possível, obtenha uma enorme quantidade de discos RAM ou SSD.