Diseño Actual Base de Datos Unificada

Pros:

Simplicidad: Mantener una única base de datos para maestros y transacciones simplifica la
arquitectura y el diseño de la aplicación. Avance actual de desarrollo

Facilidad de mantenimiento: Menos bases de datos significan menos esfuerzo en la gestión y

el mantenimiento.

Integridad de datos: Es más fácil mantener la integridad de los datos y las relaciones entre
ellos cuando todo está en una sola base.

Rendimiento en consultas simples: Para consultas que no requieren de datos segmentados, el

rendimiento podría ser mejor debido a la menor necesidad de consultas a las diferentes tablas.

Automatización: simplifica la estandarización de procesos para nuevas tarifas

Contras:

Escalabilidad: A medida que la base de datos crece, el rendimiento podría degradarse,

especialmente si hay muchas transacciones concurrentes.

Rendimiento en consultas complejas: Las consultas que involucran múltiples tablas y

relaciones pueden volverse más lentas a medida que la base de datos crece.

Flexibilidad: Menos flexibilidad para optimizar el rendimiento de consultas específicas que

podrían beneficiarse de una estructura de datos segmentada.
Diseño Bases de Datos Segmentadas

Pros:

Escalabilidad: Segmentar la base de datos puede ayudar a manejar mejor el crecimiento, al

distribuir la carga y los datos.

Optimización del rendimiento: Permite optimizar el rendimiento para consultas específicas,

ajustando índices y almacenamiento según la segmentación.

Flexibilidad: Más flexibilidad para realizar ajustes y mejoras en segmentos específicos sin
afectar el resto de la base de datos.

Resiliencia: Una falla en una de las bases de datos segmentadas puede tener un impacto
limitado, sin afectar las otras segmentaciones.

Contras:

Complejidad: Aumenta la complejidad en el diseño, la implementación y el mantenimiento de

la aplicación.

Gestión de la integridad de datos: Mantener la integridad referencial y la consistencia de los

datos a través de múltiples bases de datos puede ser más desafiante.

Rendimiento en consultas transversales: Las consultas que necesiten unir datos de varias
segmentaciones podrían tener un rendimiento peor debido a la necesidad de realizar
operaciones más complejas.

Costos de mantenimiento: Puede aumentar el esfuerzo y el costo asociados al mantenimiento

de múltiples bases de datos, incluyendo la necesidad de sincronización entre segmentos.

Ambos enfoques tienen sus ventajas y desventajas, y la elección depende de las necesidades
específicas del proyecto, el volumen de datos esperado, la complejidad de las consultas, y la
capacidad del equipo que quede encargado del mantenimiento del sistema para gestionar la
complejidad adicional que conlleva la segmentación de la base de datos. Es crucial también
considerar el crecimiento futuro y cómo cada enfoque se adaptará a las necesidades
cambiantes del sistema y su escalabilidad.

En relación a la situación actual del proyecto, el desarrollo con una sola base de datos está en
curso, en un 80% para el flujo simple y en un 50% para el flujo completo de negocio – pricing.

Damos las siguientes opciones y en base a ellas sus consecuencias:

1) Avanzar con una base de datos unificada para los flujos: negocio – pricing: flujo simple
y flujo completo. Poder implementar el desglose de las bases de datos para los
desarrollos que vienen.
2) Frenar el desarrollo actual, para poder generar el backend correspondiente a las
diferentes bases de datos. Estimamos que este cambio puede impactar con un mes
más de desarrollo para los flujos ya desarrollados.