Las bases de datos relacionales están diseñadas para almacenar muchas filas por tabla. Hay un montón de mecanismos para facilitar tablas grandes, como:
- Índices en cualquier combinación de campos para acelerar las búsquedas
- Almacenamiento en caché de páginas para que las páginas de uso común permanezcan en la memoria
- Particiones verticales (bases de datos en columnas) para acelerar aún más las solicitudes
- Algoritmos avanzados como hash joins y group bys (al menos en bases de datos que no sean MySQL)
- Uso de múltiples procesadores y discos para procesar consultas
Hay una cosa que es más difícil cuando se colocan datos en una sola tabla y es la seguridad. Y, de hecho, en algunas circunstancias, esta es una preocupación principal y básicamente requiere que los datos vayan en una tabla separada. Esas aplicaciones son raras y distantes entre sí.
Para dar un ejemplo de lo malo que podría ser almacenar datos en varias tablas, imagine que en su sistema tiene un registro por empresa y lo almacena en una tabla. Este registro almacena información sobre la empresa, algo como el nombre, la dirección, lo que sea. La llamada es de 100 bytes de información.
En su esquema, hay una tabla separada para cada "compañía", por lo que es una fila por tabla. Ese registro residirá en una página de datos. Una página de datos podría tener 16 kbytes, por lo que está desperdiciando alrededor de 15,9 kbytes para almacenar estos datos. Almacenar 1000 registros de este tipo ocupa 16 Mbytes en lugar de unas 7 páginas (112 Kbytes). Eso puede ser un impacto significativo en el rendimiento.
Además, con varias tablas, no tiene en cuenta los desafíos de mantener todas las tablas y garantizar la exactitud de los datos en las diferentes tablas. Las actualizaciones de mantenimiento deben aplicarse a miles de tablas, en lugar de a unas pocas.
