Esto es semi-hipotético, y como no tengo experiencia en el manejo de tablas de bases de datos masivas, no tengo idea de si esto es horrible por alguna razón. Sobre la situación:
Imagine una aplicación basada en la web, digamos un software de contabilidad, que tiene 20,000 clientes y cada cliente tiene más de 1000 entradas en una tabla. Son 20 millones de filas que, sin duda, pueden ralentizar las consultas complejas.
En un caso como este, ¿tiene más sentido crear una nueva tabla en la base de datos para cada cliente? ¿Cómo reaccionan las bases de datos al tener 20k (o más) tablas?
Suena como una mala idea.
No intentes burlar a la base de datos con construcciones exóticas como esta. Los motores de bases de datos están diseñados con muchas optimizaciones para manejar grandes conjuntos de datos. Por ejemplo, lo que está describiendo suena terriblemente cercano a un intento de implementar índices manualmente. Simplemente use los índices proporcionados por el motor DB, se implementan mucho mejor de lo que probablemente pueda hacer por su cuenta, y no requerirá tanto mantenimiento.
Además, como regla general. Sugiero no diseñar una base de datos de una manera que requiera manipulación o creación de estructuras de bases de datos (tablas, campos) durante el uso normal de la aplicación. Hace que la optimización del rendimiento sea un obstáculo y, a menudo, lo obliga a otorgar demasiados permisos a los usuarios para realizar tareas de rutina que podrían crear agujeros de seguridad.
fuente
Aquí hay un artículo que siempre insto a las personas a leer, cuando hacen esta pregunta:
http://datacharmer.blogspot.com/2009/03/normalization-and-smoking.html
fuente
En mi humilde opinión, una sola tabla no debería ser un problema, así que no cree un problema donde no exista una, todavía. Hay muchas cosas que puede hacer para ayudar al rendimiento. Puede particionar una sola tabla en varios archivos según el ID de cliente o un campo de fecha para ayudar con IO. Su base de datos no tiene que realizar un seguimiento, optimizar y almacenar en caché 20,000 sentencias sql diferentes para cada consulta que necesite su sitio. Puede indexar por clientid. 20 mil clientes pueden pagar una gran cantidad de hardware.
Para este tipo de tabla, se podría usar un tipo NoSQL db.
Con 20K clientes, la base de datos puede no ser su eslabón más débil, entonces, ¿por qué introducir tanta complejidad?
fuente
Ese es un mal enfoque.
Particione la tabla verticalmente, 2 servidores de bases de datos, uno para identificadores de usuario impares, y otro para pares debería funcionar bien (los datos no están relacionados entre los usuarios).
Ordene los datos por user_id y, si eso no es posible, obtenga una gran cantidad de discos RAM o SSD.
fuente