Una tabla grande afecta al rendimiento de las demás?

[wakewakeup]

Tengo una base de datos SQL Server, estamos planteandonos crear una tabla que tendrá muchos datos, no me pregunteis la cantidad pero muchos, por lo que entiendo que las consultas a esa tabla tardarán bastante (esto no me preocupa).

Mi duda es si tener esa tabla tan grande afectará a las consultas e inserciones en otras tablas del mismo esquema pero que no estén relacionadas de ninguna forma con la tabla grande.

Gracias

[gnzsoloyo]

¿A qué llamas mucho? ¿Miles? ¿Cientos d Miles? ¿Millones? Millones son poca cosa.

Lo de si la performance se ve afectada no tiene que ver sólo con la cantidad, sino con muchos otros factores: indices, consultas, relaciones, sistemas, hardware...
En una base que maneja millones de clientes, una tabla con 32 millones de registros al día puede representar nada, y ser consultada en menos de un segundo, así que como verás, es muy relativa la cosa.
Sin saber cómo es tu caso, no es posible establecer en qué punto se pueden producir cuellos de botella.

[wakewakeup]

No importa mucho la cantidad, esto pensando en plan teórico, piensa que son billones o trillones y que los indices y consultas están optimizadas...

La cosa es que si tener una tabla enorme y por lo tanto lenta afecta al rendimiento en las demás tablas que ni siquiera están relacionadas.

Gracias

[gnzsoloyo]

No importa mucho la cantidad, esto pensando en plan teórico, piensa que son billones o trillones y que los indices y consultas están optimizadas...

Los escenarios imaginarios no sirven.
En cuanto a plantearlo desde le punto de vista teórico, resulta inutil, porque ese tipo de análisis se hace sobre proyectos de sistemas reales. La teoría sólo te servirá como forma de entender lo que debes analizar.
Una tabla grande, para un sistema dado puede tener tan poco como 10.000 regisotrs, o tantos como necesitar particionarla en 1200 segmentos de 10.000.000 de registros, y aún así no afectarte la performance de la consulta.

Depende del caso.

[wakewakeup]

La cosa es que si os doy el caso completo vais a empezar a meteros con los detalles que ahora no me interesan (que si son muchos datos, que si son pocos, que si haga otra cosa) y no la pregunta en concreto que es lo que me interesa ahora mismo... y el tema se va por las ramas sin responder la pregunta, que es lo que está pasando... :)

[gnzsoloyo]

Vamos a ver si con un ejemplo se entiende por qué la cantidad de registros no es un parámetro determinante para establecer si una tabla dada afectará o no la performance.
Supongamos una tabla con un trillón de registros, es decir, 1.000.000.000.000.000.000 registros (con esa cantidad tus problemas de hardware se presentarán antes que los de performance de consultas), la cual tiene una media docena de índices, de y realizaremos una consulta con tres parámetros, todos indexados.
Los indices usados tendrán 500.000 entradas uno, 20.000 entradas el otro, y el tercero unas 100.000 (considerando que es un trillón de registros, estoy siendo pesimista).
- En ese contexto, la tabla no se leerá directamente, sino que el sistema usará los índices.
- El primer índice permitirá descartar, desde el inicio alrededor del 99,98% de los registros, quedando sólo 2.000.000.000.0000 de registros.
- El segundo índice devolvería más, pero como sólo se buscarán sobre los 20 billones restantes, quedarían 100.000.000 registros.
- El tercer índice dejaría finalmente 1.000 registros a leer, por lo que en realidad sólo se leerán de la tabla esos, y será en esos donde se buscará.

¿Crees realmente que una tabla de un trillón de registros afectaría la performance, si está bien optimizada como dices?

Ahora bien, supongamos que tenemos un caso de una tabla con 10.000 registros, los cuales se pueden leer en servidor en 7,2 segundos, haciendo una pésima consulta.
Pero la consultas por intranet, y te encuentras que tarda 36,7 segundos (me han pasado cosas así).
¿Es grande la tabla?
No.
¿Está optimizada?
Si.
La intentas consultar en web y luego de 40 minutos, el servidor se cae, sin haber obtenido resultados.
¿Cómo es posible? Al menos debería poder devolverte esos resultados en un minuto.
¿Dónde falló?
Falló porque algún inútil usó la tabla para almacenar imágenes digitales en su formato binario, y la consulta está devolviendo un resultado de 72 Gb de datos, que hacen caer al servidor web...
¿La tabla es grande?
En registro, no. Pero es demasiado grande en datos para ser usada en Web, mientras que en localhost anda perfectamente.

Sintetizando: Una tabla es grande o pequeña en función del diseño del sistema, y no de la cantidad de registros. Por ende, puede ser poco performántica incluso con pocos, y muy performántica con cantidades exorbitantes de registros.

¿Se entiende?

Lo que hay que hacer es un análisis de requerimientos para arquitectura de datos, y allí es donde se resolverá eso. Es lo que hacemos todos en ese caso.
Pero no existen modelos absolutos. Lo que existen son "casos de estudio" (que puedes consultar en la web oficial o en otras dedicadas al tema), y los casos de estudio aplican si el contexto de tu sistema puede se comparado con ellos. Pero no se puede teorizar en el aire.

Lo único que te puedo recomendar, dado que no nos quieres dar un escenario de uso es que si quieres evitarte problemas, verifica con el plan de consultas que jamás se produzcan casos de full table scan, porque eso si te matará al sistema.