¿Debo usar una base de datos por aplicación o compartir una sola base de datos entre múltiples aplicaciones [cerrado]

Tengo varias aplicaciones, algunas que usan datos de las mismas fuentes. ¿Es la mejor práctica (o cuáles son los pros / contras) para:

• dejar los datos en bases de datos compartidas por múltiples aplicaciones

  1. ahorra espacio ya que solo se necesita una base de datos
  2. complica la indexación ya que diferentes aplicaciones tienen diferentes necesidades de consulta

• importar datos diariamente en bases de datos por aplicación

  1. usa más espacio ya que existen datos duplicados en las bases de datos por aplicación
  2. indexación más fácil ya que cada aplicación puede enfocarse en sus necesidades individuales

Es posible que haya dejado de lado otras ventajas / desventajas, por favor enumere si las hay, ¿cómo se hace esto en su lugar de trabajo?

El espacio es barato en estos días, por lo que recomendaría usar una base de datos por aplicación.

Compartir una base de datos para múltiples aplicaciones tiene algunas desventajas serias :

• Mientras más aplicaciones usen la misma base de datos, es más probable que llegue a cuellos de botella de rendimiento y que no pueda escalar fácilmente la carga como lo desee . Las bases de datos SQL no se escalan realmente. ¡Puedes comprar máquinas más grandes pero no se escalan bien en grupos!

• Los costos de mantenimiento y desarrollo pueden aumentar : el desarrollo es más difícil si una aplicación necesita usar estructuras de bases de datos que no son adecuadas para la tarea en cuestión, pero que deben usarse ya que ya están presentes. También es probable que los ajustes de una aplicación tengan efectos secundarios en otras aplicaciones ("¿por qué hay un disparador tan innecesario?" / "¡Ya no necesitamos esos datos!"). Ya es difícil con una base de datos para una sola aplicación, cuando los desarrolladores no pueden / no pueden conocer todos los casos de uso.

• La administración se vuelve más difícil: ¿qué objeto pertenece a qué aplicación? El caos aumenta. ¿Dónde tengo que buscar mis datos? ¿Qué usuario puede interactuar con qué objetos? ¿Qué puedo conceder a quién?

• Actualización: necesitará una versión que sea el mínimo común denominador para todas las aplicaciones que lo utilicen. Eso significa que ciertas aplicaciones no podrán usar funciones potentes. Tendrás que seguir con las versiones anteriores. También aumenta un poco los costos de desarrollo.

• Concurrencia: ¿Puede realmente estar seguro de que no hay dependencias cronológicas entre los procesos? ¿Qué sucede si una aplicación modifica datos que están desactualizados o que otra aplicación debería haber modificado antes? ¿Qué pasa con las diferentes aplicaciones que trabajan en las mismas tablas al mismo tiempo?

En comparación con eso, los procesos de importación de datos / ETL son casi siempre bastante sencillos y directos. Cargue los datos con la frecuencia que necesite, el espacio es barato. Puede dar cuenta de la escalabilidad de cada aplicación de forma independiente, ajustar y ajustar las estructuras según las necesite y no habrá problemas de concurrencia. Los efectos secundarios también se pueden rastrear mucho más fácilmente.

Editar: Sin embargo, me gustaría señalar que, como mencionó @Saeed, si puede encapsular las manipulaciones de datos en un servicio que está comúnmente disponible, entonces es más fácil compartir una base de datos con múltiples aplicaciones. Siempre y cuando no necesite acceso sin procesar, es un muy buen enfoque.

Tuve una situación similar una vez. Mi problema era crear 3 aplicaciones, una para la gestión de inventario, una para la gestión de compras y otra para la gestión de usuarios, es decir, empleados. Mi recomendación es no romper físicamente las bases de datos por aplicación, ni unirlas físicamente por aplicación. Más bien, la separación lógica en mi humilde opinión funciona mejor.

Por ejemplo, las 3 aplicaciones necesitaban trabajar con información de los empleados. Tanto los sistemas de inventario como de adquisiciones estaban utilizando la misma información de bienes y artículos de inventario.

Creé una base de datos compartida, en la que almacenaba la información de usuarios y bienes. Luego construí una capa de servicio encima y usé esos servicios en otras aplicaciones. Para mostrar una lista de todos los empleados que ahora están en la empresa, por ejemplo, solo necesitaba llamar a un método del servicio como GetOnWorkEmployees().

También creé una interfaz de usuario común para interactuar con usuarios y productos, que era una aplicación web separada en sí misma.

Entonces, agregando a lo que @Falcon ha señalado, creo que puede beneficiarse de centralizar la funcionalidad común entre las aplicaciones en una base de datos.

Si estas aplicaciones están destinadas a trabajar con los mismos datos, por ejemplo, la misma lista de productos y clientes, mantenga la base de datos unida. No gana nada separando las bases de datos. Eso es puramente un problema 'humano': para el servidor, solo sus bytes en un disco. No le importa si son 1 o 100 bases de datos. Pero si lo divide, debe lidiar con la sincronización de datos. Los problemas de indexación que menciona no son un problema real: pasaría la misma cantidad de tiempo de procesador manteniendo los índices si los db se dividieran.

Si el rendimiento comienza a convertirse en un problema, replica la base de datos en varios servidores para equilibrar las cosas.

Puede valer o no la compensación en su situación, pero mantener la integridad de los datos es más fácil con una sola base de datos. Al menos en MS SQL Server, no se puede forzar una clave externa de una base de datos a una base de datos diferente. Puede simular el comportamiento de la clave externa con desencadenantes, pero no es particularmente elegante.

Además, crear copias locales de los datos puede ser peligroso cuando entran en juego las escrituras. Si AppA y AppB tienen una copia de algunos datos compartidos y AppA la actualiza, AppB seguirá teniendo los datos antiguos. O bien, deberá configurar disparadores para mantener los datos sincronizados.

Una vez tuve varios sitios web que se hicieron populares con el tiempo. Usaron bases de datos separadas, principalmente porque el proveedor de alojamiento permitía solo 1Gb de espacio de almacenamiento cada una. ¡Pero! Tan pronto como lancé un servicio que incluía todos estos sitios web, comencé a tener que hacer transacciones entre estos sitios web, y la forma más conveniente de hacerlo es definitivamente mover todo a una gran base de datos.

Así que optimicé la estructura de la base de datos y exprimí las partes relevantes de esta base de datos central, pero dejé todo lo demás fuera.

Mi opinión está relacionada de alguna manera con los paradigmas de la POO. Los datos similares deben almacenarse juntos, por lo que si crea aplicaciones diferentes, debe usar diferentes bases de datos para ellas.

En el caso anterior, no se pudo evitar el uso de db común, pero recuerde que también mantuve algunas tablas separadas en un db separado, que no son parte de las consultas comunes.

Además, si los mantiene separados, será más fácil hacer una copia de seguridad, habrá menos posibilidades de pérdida de datos. Si algo sale mal y las aplicaciones interfieren entre sí, la base de datos se arruina y, básicamente, no desea exponer su aplicación a este peligro.

Con todo, puede mantener una base de datos común para consultas comunes, pero también mantener una para cada una de sus aplicaciones.

¿Puede elaborar más sobre la arquitectura de su aplicación?

Si su base de datos funciona solo como un repositorio de datos sin lógica de aplicación, como disparadores o código de paquete comercial, sería mejor tener una sola base de datos y encapsular la funcionalidad de nivel comercial a los servicios que usan la base de datos para todas sus acciones. Si tiene activadores o código en el esquema de la base de datos, se encontrará con grandes problemas al usar una única base de datos que puede ser problemática en muchos casos.