Estaba trabajando en un nuevo proyecto que tiene el requisito de usar 7 bases de datos, argumentando que el rendimiento, la estabilidad y la optimización se implementan más fácilmente.
Si bien no estoy de acuerdo, tengo problemas para recopilar buenos argumentos para usar una sola base de datos (dividir las tablas en dominios lógicos).
Un argumento que tengo hasta ahora es la integridad de los datos (no puedo usar claves externas entre bases de datos).
¿Cuáles son los buenos pros / contras para usar una o varias bases de datos?
[resumen hasta ahora]
Argumentos contra múltiples bases de datos:
Pérdida de integridad de datos (no se pueden usar claves foráneas sobre bases de datos)
Perder la integridad de la restauración
Ganar complejidad (usuarios de db / roles)
El servidor / la base de datos de cuotas pequeñas caerán
Soluciones:
Usa esquemas para separar dominios.
POC: utilice datos ficticios para demostrar el punto en los planes de ejecución de 7/1 db
Respuestas:
Nada de rendimiento, estabilidad, optimización es cierto. ¿Alguien tiene un argumento sólido o un artículo de referencia por qué esto sería cierto?
Los recursos no se asignan a una base de datos: la instancia de SQL Server equilibra los recursos, por lo que no hay diferencia
Tú pierdes:
Ganas complejidad:
Opciones:
fuente
Las buenas razones para crear bases de datos separadas serían admitir diferentes requisitos de disponibilidad o simplificar la administración. Por ejemplo, si sus bases de datos requieren horarios de copia de seguridad muy diferentes o diferentes modelos de recuperación. Otra razón sería si desea ejecutarlos en diferentes instancias.
No hay optimizaciones de rendimiento disponibles con múltiples bases de datos que tampoco puede lograr con una base de datos. ¿Puede dar más detalles sobre lo que quiere decir con "rendimiento, estabilidad, optimización"?
fuente
Si después de dividir los datos por dominio lógico, siempre puede ver el uso de esquemas dentro de SQL2008 (alejándose del valor predeterminado de dbo), pero incluso eso es doloroso y puede causar problemas con OR / M que no esperan un no -esquema estándar.
He estado en la posición de recopilar datos de más de una base de datos y es doloroso y está lejos de ser de alto rendimiento. Terminas almacenando datos en caché o al menos usando trucos para mantener la velocidad.
Como prueba, construya 7 bases de datos ficticias. Cree una consulta que requiera datos simultáneamente de los 7, o al menos un buen número de ellos.
¡Entonces compara los planes de ejecución! Creo que ganarás tu caso allí mismo.
fuente
Experimento de pensamiento: en lugar de dividir su base de datos en siete partes, divídala en 7,000 partes. ¿Cuál es la probabilidad de que una falla de hardware afecte su aplicación? Si hay un 0.1% de posibilidades de que un servidor en particular muera en un día en particular, ¿son sus posibilidades mejores o peores de que se vea afectado por una falla de hardware al aumentar la cantidad de máquinas de las que depende?
Creo que es importante dividir la noción de "la base de datos" en dos partes: el esquema y los datos frente al hardware que se utiliza para servir los datos.
Romper la base de datos en varias máquinas no sirve de nada por las muchas razones explicadas por las otras respuestas en este tema.
Si va a utilizar varias máquinas para obtener confiabilidad y un rendimiento mejorado, tal vez pueda estructurarlas de modo que tenga un servidor maestro con múltiples máquinas de espera en caliente / caliente que también podrían usarse para distribuir consultas. De esta forma, si alguna máquina experimenta un error, no pierde datos y, en el peor de los casos, tendrá que reiniciar una consulta. Por supuesto, es más complejo que esto, pero se aplican los conceptos básicos.
fuente
Estoy de acuerdo con una base de datos y en su lugar uso las opciones de archivo y esquema.
Hay casos extremos donde la división en varias piezas tiene sentido.
Configuración del entorno de aplicación (desarrollo, prueba, producción), como servidores FTP, rutas de archivos de exportación, etc., Cosas que desea almacenar por servidor y no sobrescribir en una restauración.
También como una forma de aislar los cambios de procedimientos específicos del cliente.
Pero estos son problemas de soporte y no de rendimiento.
fuente