ADR-0004 · Una sola base de datos para todos los módulos

ADR-0004 · Una sola base de datos para todos los módulos

  • Status: ✅ Accepted
  • Fecha: 2026-02-20
  • Tags: bd · arquitectura

Contexto

Los 5 módulos (venta, caja, cashflow, articulos, listas) necesitan compartir datos:

  • venta JOIN articulos_raw (peso enriquecido).
  • caja/finanzas JOIN ventas (rentabilidad cruzada).
  • cashflow lee ventas (cruce comercial 6 meses) + caja_raw_egresos_caja (saldo).

Opciones consideradas

Opción A · BD por módulo + ETL nocturno

  • ❌ Hostinger shared no facilita múltiples BDs.
  • ❌ ETL nocturno = latencia.
  • ❌ Complejidad innecesaria para el tamaño actual.

Opción B · Microservicios + API REST entre módulos

  • ❌ Overkill para 1-2 devs.
  • ❌ Sobrecarga de red interna.

Opción C · Una BD compartida (★ elegida)

  • ✅ JOINs nativos directos.
  • ✅ Consistencia transaccional gratis.
  • ✅ Una sola conexión PDO singleton.
  • ⚠️ Acoplamiento, pero tolerable a esta escala.

Decisión

Usar u120688891_chess como base única para los 5 módulos.

Prefijos para evitar colisiones:

  • ventas, sincronizaciones — sin prefijo (es el módulo "principal")
  • caja_* — 10 tablas
  • cashflow_* — 4 tablas
  • articulos_* — 7 tablas (raw + precios + agrupaciones)
  • listas_sync — metadata

Consecuencias

✅ JOINs cross-module triviales (ej. caja/finanzas/cruce_ventas.php). ✅ Backup único. ✅ Consistencia transaccional. ⚠️ Si un módulo crece a 10M+ filas, vuelve a ser cuello de botella. ⚠️ Requiere disciplina: cada módulo NO modifica tablas de otros sin coordinación.

Plan de evolución

Cuando algún módulo necesite escalar más:

  1. Réplica de lectura (slave) para consultas pesadas.
  2. Particionado por sync_id (ya planificado para ventas cuando > 2M filas).
  3. Eventual separación a BD dedicada con event sourcing.

Detalle en Análisis · §12 Escalabilidad.

Referencias