¿Cuáles son las ventajas y desventajas de las mejores prácticas para usar una única base de datos?

Question

Aquí en el trabajo (una compañía de fabricación multimillonaria con un equipo de desarrollo de Windows de 12 personas) estamos a punto de ir a una única base de datos maestra para todas las aplicaciones nuevas y la dividiremos con esquemas de lo que normalmente tendríamos bases de datos para antes. También habrá algunos esquemas comunes con cosas como el directorio de empleados y el directorio de sucursal y así sucesivamente ...

Todavía no estoy seguro de cómo me siento sobre este cambio, pero estamos a punto de tener una reunión sobre este tema en unas pocas horas para analizar los pros, los contras, las mejores prácticas, las trampas, etc., así que estoy buscando su opinión sobre esto ... ¿Es bueno? ¿Es mala? ¿A qué problemas nos enfrentaremos en un año a partir de ahora?

Cualquier pensamiento, consejo o consejo es bienvenido. Gracias

EDITAR En respuesta a un comentario sobre esta cuestión, estamos utilizando SQL Server 2005 y en realidad estamos hablando de mover lo que habría sido bases de datos separadas en la misma instancia en una sola base de datos. El problema principal es la falta total de integridad referencial en las bases de datos, ya que la mayoría de nuestras aplicaciones necesitan acceder a datos comunes, como un registro de empleado o información de sucursal.

ACTUALIZACIÓN Varias personas solicitaron que actualizo esta cuestión con los resultados de nuestra reunión así que aquí está. Debatimos sobre los pros y contras de los pros y los contras de hacer esto (incluso les mostré esta pregunta usando el proyector) y para el momento en que terminamos cubrimos los pros y los contras aquí. Alrededor de la mitad de nosotros pensamos que podríamos hacerlo con los recursos y el compromiso correctos, y la mitad pensamos que no podríamos hacerlo (o que no funcionaría bien). Decidimos utilizar algo de tiempo con Microsoft para obtener sus opiniones y consejos específicos de la plataforma. Me aseguraré de actualizar esta pregunta y my blog después de que hayamos hablado con ellos. Gracias por toda la ayuda y respuestas útiles.

Answer 1

más grande base de datos son más difíciles de mantener debido al enorme tamaño: copias de seguridad llevan más tiempo, la recuperación de desastres es más lento que a su vez requiere más a menudo copias de seguridad.Puede abordar estos creando grupos de archivos y usando filegroup level backup en sus planes de mantenimiento y en la recuperación de fallos puede usar la estrategia 'piecemeal restore' para acelerar las cosas.

El uso adecuado de grupos de archivos hará desaparecer la mayoría de los "contras" citados en las respuestas anteriores: pueden distribuir E/S, pueden desinfectar sus planes de mantenimiento y estrategia de copia de seguridad/restauración, ofrecen disponibilidad solo al estar fuera de línea la parte dañada del DB en caso de falla. Entonces, yo diría que, si bien esos "contras" son preocupaciones legítimas, se pueden mitigar mediante una estrategia de implementación adecuada. Es cierto, sin embargo, que estas acciones de mitigación requieren un verdadero y experimentado dba al mando, ya que irán más allá de la zona de confort de un desarrollador que se convierte en dba por necesidad.

Algunas de las ventajas que se me ocurre de forma rápida:

1. consistencia. Puede tener una restauración de copia de seguridad para que todos los datos sean coherentes. Los dbs separados no permiten esto porque no puede coordinar un conjunto coherente de copias de seguridad a menos que las desconecte todas o las haga r/o durante la copia de seguridad.
2. Alta disponibilidad barata de suciedad: puede implementar database mirroring para recuperabilidad ante desastres y alta disponibilidad. Varias bases de datos tienen problemas porque no se puede coordinar una conmutación por error simultánea y las aplicaciones se enfrentan con el dilema de buscar cada ubicación actual de la base de datos.
3. Seguridad. Si bien la mayoría de las otras publicaciones consideran que una de las bases de datos es más difícil de proteger, yo diría que es más fácil para asegurar. Múltiples bases de datos parecen más difíciles de asegurar de manera adecuada simplemente porque lo que todos hacen es hacer un inicio de sesión y agregarlo al que base de datos grupo db_owner. Tener una base de datos hará las cosas más difíciles (a menos que termines dbo a todos, muy mal) pero una vez que comiences a hacer lo correcto (acceso granular), entonces una db no es más difícil que múltiples dbs, en realidad es más fácil porque no tendrás para copiar/mantener algunos grupos/derechos comunes en múltiples dbs.
4. Control. Será más fácil imponer ciertas políticas y buenas prácticas en un solo db en lugar de múltiples (sin acceso a los datos de los desarrolladores, acceso a los datos de la aplicación solo a través de derechos de ejecución en el esquema para imponer el acceso a los procedimientos, etc.).

también hay algunos inconvenientes que no veo en otros mensajes:

1. Esto será mucho más difícil de lograr que cree que en este momento
2. Aumentar el acoplamiento entre las aplicaciones que antes estaban separados impondrán desarrollo Restricciones: no puede simplemente alterar su esquema, deberá coordinarlo con el resto de las aplicaciones (puede argumentar que este también fue el caso anterior, pero se borró bajo la alfombra al tener dbs separados, y está derecha)
3. Escrituras de registro que ahora se distribuyen acro ss múltiples registros db se consolidarán en un único archivo de registro. Si sus escrituras son significativas, esto puede convertirse en un serio cuello de botella y obligarlo a comprar algunas unidades rápidas costosas para el nuevo archivo de registro consolidado. En general, esto se puede solucionar haciendo que el registro maneje una matriz despojada en tantas franjas como sea necesario para que sea lo suficientemente rápida (generalmente incursión 10).
4. GAM/SGAM/PFS asignaciones también se consolidarán, pero una vez más esto se aliviará mediante el uso adecuado de grupos de archivos.

Answer 2

Si DB es cada vez más grande, hacer copias de seguridad es cada vez más difícil debido a su tamaño.

Answer 3

Esto podría significar un serio problema de escalabilidad si desea agregar aplicaciones de alto tráfico en el futuro, ya que es mucho más fácil agregar nuevos servidores de bases de datos que ejecutan dbs separados que para paralelizar una única base de datos. Al menos en SQL Server.

Answer 4

Pros:

• La comodidad de tener todo en un solo lugar
• pensar menos en un buen diseño de base de datos

Contras:

• las cosas aún no relacionados se encuentran en un solo lugar
• Menos pensando en ir Diseño de base de datos od que conduce a datos poco normalizados

Para mí, esto suena a pereza y la creencia de que todo este "material de base de lujo de la torre de marfil" no tiene valor.

Answer 5

Veo que da miedo, pero teniendo en cuenta la cantidad de empresas que usan Oracle EBS o SAP u otros sistemas que son, en esencia, esta misma configuración, no creo que sea una mala cosa ™.Es un gran paso, y será difícil para corregir, pero realmente puede mejorar la integración en toda la empresa en el largo plazo.

Answer 6

Nunca he oído hablar de este enfoque y me gustaría saber cómo va la reunión. No veo ningún beneficio real al combinar múltiples aplicaciones en una sola base de datos cuando los datos no se relacionan entre sí.

Estoy pensando que podría tener problemas si decide que una aplicación requiere su propio servidor de base de datos en un punto.

Answer 7

El único "Pro" que puedo pensar es que todos sus sistemas estarán en una base de datos y por lo tanto un lugar único para realizar copias de seguridad, almacenar, etc. Sin embargo, consideraría que también es uno de los más grandes "Contras".

Algunos otros Contras generales:

• mucho más difícil de mover una aplicación a un lugar/servidor diferente en el futuro.
• Posibles problemas de bloqueo si alguna aplicación utiliza tempdb.
• Posible desproporción de rendimiento no relacionado en una aplicación cuando se está utilizando otra aplicación.
• Mucho más difícil de implementar un modelo de seguridad de nivel de aplicación si todas las tablas están en la misma base de datos.

Answer 8

Ah, el viejo patrón de diseño EggsInOneBasket. No es un favorito.

Usted está agravando cualquier problema causado por el daño a esa base de datos. ¡Difunde el riesgo!

Answer 9

Pros:

• Sólo es necesario recordar la secuencia una conexión
• Cuando los usuarios informan de que el acceso es lento, ya sabes lo que DB está causando el problema

Contras:

• Las copias de seguridad de The One DB demorarán un tiempo prolongado y se alargarán progresivamente con el tiempo.
• Restaurar los datos de una copia de seguridad será cada vez más difícil.
• El ajuste del rendimiento (Analizador de SQL, estimación del plan de ejecución) para una función de una aplicación reducirá la velocidad de cada aplicación.
• Restringir el acceso a los datos de una sola aplicación es engorroso si es posible, lo que probablemente signifique en la práctica que a todos los desarrolladores y DBA se les den claves para TODO el reino.
• Los nuevos desarrolladores/DBA tienen una curva de aprendizaje mucho más grande, ya que necesitan navegar una estructura de base de datos grande y en su mayor parte inútil (para ellos) lo que significa mayores costos de capacitación/aumento gradual.
• Cuando la base de datos One se cae, todos en su organización juegan al solitario hasta que se restaure.
• Creación de instancias de prueba para el desarrollo de aplicaciones significa copiar toda su base de datos

Answer 10

Me parece que su empresa está haciendo una transición entre dos motivos completamente distintos para usar la tecnología de bases de datos. El primero es el soporte de la aplicación. El segundo es la integración de datos.Si estoy en lo cierto al respecto, el proceso abrirá una gran cantidad de gusanos, y muchos de los problemas ni siquiera serán abordados al poner todos los datos en una gran base de datos.

Considera dos de los puntos que hiciste. El primero es la completa falta de integridad referencial en diferentes bases de datos. El segundo es la idea de que cada aplicación tendrá su propio esquema. Lo que esto permite que suceda es una completa falta de integridad referencial en todos los esquemas, que te devuelve a las arenas movedizas en las que te encuentras ahora.

Arreglar los datos para que la integridad referencial esté presente, y corregir los esquemas para que se aplique la integridad referencial, y arreglar las aplicaciones para que las aplicaciones coincidan con los nuevos esquemas resultará una tarea monumental.

Esto es lo que su empresa realmente necesita hacer: tener una única base de datos CONCEPTUAL que contenga todos los "datos empresariales", y definida de manera que se apliquen la integridad referencial y la integridad de la entidad. Revise los esquemas existentes para que se ajusten a la base de datos CONCEPTUAL excepto por los datos que son puramente locales para ese esquema y no documentados en la base de datos conceptual unificada. Use restricciones donde sea necesario para garantizar que los datos cubiertos por estos esquemas no pierdan integridad.

Decida si estos esquemas pertenecen a una base de datos o a muchas bases de datos basadas en la administración de la base de datos, fallan los requisitos de seguridad y rendimiento, y NO a la necesidad de integrar datos. Si usa una plataforma o varias plataformas es una decisión separable.

Donde sea necesario, mantenga copias sincronizadas de los mismos datos en bases de datos separadas. Incluya la sobrecarga de hacer esto en sus consideraciones de rendimiento anteriores.

Documente la base de datos conceptual del gazoo. No se conforme con las definiciones de la FORMA de los datos. Insista en las definiciones de la semántica de los datos también.

Tenga en cuenta que si utiliza campos de ID en lugar de claves naturales para imponer integridad referencial, deberá generar cada campo de ID en un esquema y permitir que la asociación entre ID y datos dependientes se propague mediante sinónimos, vistas y replicación sincronizada.

Esto no va a ser fácil.

Answer 11

Para el problema de integridad referencial, puede hacer copias de esas tablas compartidas en las bases de datos subsidiarias. No puede usar la replicación real, pero lo que hace es denegar todo, pero seleccione esto para la mayoría de los usuarios.

En el mismo servidor, puede enviar o extraer datos del repositorio oficial de los datos maestros e insertar nuevas filas/actualizar las filas modificadas. Incluso puede hacer esto con un desencadenador en la base de datos maestra (aunque no lo recomiendo).

Si se trata de instancias o servidores diferentes, puede usar servidores vinculados o SSIS.

Puede poner los datos comunes en un esquema "central" en cada base de datos. Luego puede tener herramientas para verificar que todas sus tablas centrales en cada base de datos subsidiaria sean consistentes. Lo peor que puede pasar es que una aplicación no está viendo a un nuevo empleado porque el núcleo no está actualizado. Y mantener su base de datos separada le da la capacidad de desacoplarse y le da ventanas de mantenimiento. (Incluso puede desacoplar y ejecutar "independiente" si su maestro está inactivo para mantenimiento).

Espero que solo veas algunas docenas de estas tablas de entidades centrales incluso en una empresa bastante grande.

Answer 12

Hay muchas otras formas de resolver el problema de la integridad referencial (RI). No estoy tan familiarizado con SQL Server como otros DB. En Informix puede usar sinónimos para señalar objetos en otros DB y usarlos para su RI. En Oracle puede hacer un enlace DB a uno o más DB para lograr lo mismo. Estos enfoques tienen el problema de que si alguno de los DB está caído, el RI fallará y causará problemas en los DB dependientes. Selects funcionaría, pero las inserciones fallarían. La consolidación puede ser una buena idea, dependiendo del tamaño del esquema, y ​​otros problemas con la escalabilidad. SQL Server tiene serios problemas de escalabilidad. Otras plataformas de DB permiten escalar horizontalmente con un enfoque compartir todo (RAC de Oracle, última versión de Informix) o compartir particiones sin nada (DPF de DB2, Informix XPS, Netezza, Teradata)

Estoy con algunos de los otros aquí interesados para escuchar los resultados de su reunión.