"Gran base de datos" es un concepto nebuloso. Ya hay respuestas y opiniones muy diferentes publicadas en las respuestas a esta pregunta. Algunos enfoques para definir bases de datos “pequeñas”, “medianas” y “grandes” pueden tener más sentido que otros, PERO ENTONCES, en algún momento, considero que cada definición es correcta, verdadera y válida.
Algunas definiciones tienen más sentido que otras porque se enfocan en diferentes aspectos de importancia para el diseño, programación, uso, mantenimiento y administración de una Base de Datos y estos diferentes aspectos son los que realmente importan para una Base de Datos utilizable. Simplemente sucede que todos estos aspectos se ven afectados por el nebuloso concepto de "tamaño de la base de datos".
Entonces, ¿esto significa que no importa si puede definir si una base de datos en particular es grande o no?
Ciertamente no. Lo que significa es que aplicará el concepto de manera diferente mientras evalúa diferentes aspectos de diseño / operativos / administrativos de su base de datos. También significa que cada vez este concepto será nebuloso.
Por ejemplo: la estrategia del índice de la base de datos (un aspecto del diseño de la base de datos) se ve afectada por el recuento de registros de cada tabla (una medida del "tamaño"), por el tamaño del registro multiplicado por el recuento de registros (otra medida del "tamaño") y por las consultas vs. . Proporción de operaciones de creación / actualización / eliminación (un aspecto del uso de la base de datos).
Los tiempos de respuesta a las consultas son mejores si se utilizan índices para tablas con una gran cantidad de registros. Dependiendo de la naturaleza de sus cláusulas WHERE, ORDER BY y de agregación de registros, es posible que necesite varios índices para ciertas tablas.
Las operaciones de creación, actualización y eliminación se ven afectadas negativamente por el aumento del número de índices en las tablas afectadas. Más índices para una tabla afectada significan más cambios que el RDBMS debe realizar, gastando más tiempo y más recursos para aplicar esos cambios.
Además, si su RDBMS dedica más tiempo a aplicar esos cambios, los bloqueos también se mantienen durante más tiempo, lo que afecta los tiempos de respuesta y otras consultas que se envían al sistema al mismo tiempo.
Entonces, ¿cómo equilibra la cantidad y el diseño de sus índices? ¿Cómo saber si necesita un índice adicional y si al agregar ese índice no estará introduciendo un gran impacto negativo en los tiempos de respuesta de las consultas? Respuesta: Prueba y perfila su base de datos contra una carga objetivo según sus requisitos de carga / rendimiento y analiza los datos de perfilado para descubrir si se necesitan más optimizaciones / rediseños / índices.
Se requieren diferentes estrategias de índice para diferentes consultas vs. Ratios de operaciones de creación / actualización / eliminación. Si su base de datos tiene una gran cantidad de consultas pero rara vez se actualiza, el rendimiento de la aplicación en general será mejor si agrega todos los índices que mejoran los tiempos de respuesta de las consultas. Por otro lado, si su base de datos se actualiza constantemente pero no hay grandes operaciones de consulta, entonces el rendimiento será mejor si usa menos índices.
Por supuesto, hay otros aspectos: diseño de esquema de base de datos, estrategia de almacenamiento, diseño de red, estrategia de copia de seguridad, procedimientos almacenados / activadores / etc. programación, programación de aplicaciones (contra la base de datos), etc. Todos estos aspectos se ven afectados de manera diferente por distintos conceptos de “tamaño” (tamaño de registro, recuento de registros, tamaño de índice, recuento de índice, diseño de esquema, tamaño de almacenamiento, etc.).
Me gustaría tener más tiempo ya que este tema es fascinante. Espero que esta pequeña contribución le sirva de punto de partida en este fascinante mundo de SQL.