Modelo de Datos

Vista simplificada del flujo entre el catálogo de contenido y el reproductor: los metadatos viajan del backend al cliente para armar la experiencia de reproducción.

Solución desarrollada

Criterios de aceptación

Esquema y evolución

CarpetaDigital vs CarpetaDigital_dev

Comparación de dos volcados lógicos de MySQL: la base de desarrollo amplía el modelo con workflows por mundo, informes de facturación, alertas y membresía de equipos; producción mantiene una capa de vistas de BI y dependencias con la base Validaciones.

Resumen ejecutivo

28 → 40 tablas baseProducción: CREATE TABLE esenciales. Dev: +12 tablas para workflow, alertas, informes y multi-mundo.

• 14 vistas con SQL real en prod vs 2 en dev (una es stub)
• Función calcular_horas_laborales solo en prod

Alcance en desarrollo

Nuevas piezas: mundo, estados, workflow_version, informe_facturacion, auditoría de transiciones, alerts / reglas, notificaciones, eventos de carpeta y equipo_usuarios.

Columna Mundo en Usuarios e clientes_instancia_compra (nuevos / usados).

Paridad y riesgos

Las vistas de reporting en prod enlazan Validaciones; el stub de CARPETAS_FACTURADAS en dev no reproduce esa semántica. Convive Estado numérico heredado con el catálogo estados.

Objetivo: decisiones de migración y reporting con datos alineados al negocio, no solo al volcado.

Contexto técnico

-- Volcados analizados (mismo host, mismo día)
-- Producción: CarpetaDigital      → MySQL 8.0.44
-- Desarrollo:  CarpetaDigital_dev → MySQL 8.4.7
--
-- Dev añade +12 tablas netas (mundos, workflow, informe_facturacion,
-- alerts/reglas, notificaciones, equipo_usuarios, push_subscriptions, …)
-- Prod conserva 14 vistas de reporting + función calcular_horas_laborales;
-- en dev, CARPETAS_FACTURADAS es placeholder hasta alinear Validaciones.

Próximos pasos sugeridos

1. 1. Restaurar o redefinir vistas de prod en dev si se necesita paridad BI (Validaciones, horas laborales).
2. 2. Sustituir el stub de CARPETAS_FACTURADAS o documentar la omisión deliberada.
3. 3. Alinear versiones MySQL 8.0.44 vs 8.4.7 en CI/staging si el comportamiento importa.
4. 4. Reconciliar código que usa Estado entero con estados e informe_facturacion.

Documentación

Referencia técnica completa

Tablas, vistas, diagrama ER y tablas de volumen del documento de análisis estático.

Investigación de esquema: CarpetaDigital (volcado producción) vs CarpetaDigital_dev (desarrollo)

Este documento compara dos volcados lógicos de MySQL tomados el mismo día desde el mismo host, con distinto nombre de base de datos. Fuentes:

• Producción / original: dump-CarpetaDigital.sql — base CarpetaDigital, MySQL 8.0.44
• Desarrollo: dump-CarpetaDigital_dev.sql — base CarpetaDigital_dev, MySQL 8.4.7

La base de desarrollo es una rama ampliada: incorpora tablas nuevas para flujos de trabajo (workflows), alertas, notificaciones, membresía de equipos, informes de facturación (informe_facturacion) y un modelo multi-mundo (nuevos vs usados). El volcado de producción conserva una capa de vistas de reporting más completa y una función almacenada que el volcado de desarrollo no incluye (o sustituye por stubs / definiciones vacías).

---

1Resumen ejecutivo

Área	Producción (CarpetaDigital)	Desarrollo (CarpetaDigital_dev)
Tablas base	28 objetos CREATE TABLE	40 (+12 tablas nuevas netas)
Vistas (definidas al final del archivo)	14 vistas con SELECT reales	2 vistas; una es un marcador de posición
Rutinas	Función calcular_horas_laborales	No aparece en el volcado
Dependencias entre bases	Varias vistas unen Validaciones.Validaciones (y Validaciones.NewTable)	El stub de CARPETAS_FACTURADAS no las usa (ver §5)

En desarrollo se añaden versionado de workflow, catálogo de estados por mundo, reglas de alerta y eventos de alerta, notificaciones de usuario, suscripciones push, relación muchos a muchos usuario–equipo, y una entidad de primer nivel informe_facturacion con auditoría. Las tablas núcleo compartidas están alineadas en lo esencial; el cambio principal en columnas existentes es Mundo en usuarios e instancias de compra para separar la semántica nuevos/usados.

---

2Tablas nuevas (solo en CarpetaDigital_dev)

Estas tablas no tienen un CREATE TABLE equivalente en el volcado de producción.

2.1mundo

Tabla de referencia para los "mundos" de negocio (por ejemplo nuevos vs usados). La referencian estados, alerts y workflow_version.

Columna	Notas
id	int unsigned, PK, auto-increment
codigo	varchar(50), único
descripcion	varchar(200)
activo	tinyint(1), por defecto 1

Papel: Dimensión central para acotar estados, definiciones de alertas y versiones de workflow.

---

2.2estados

Sustituye la idea de un "estado" plano como entero en la aplicación por un catálogo ligado a mundo.

Columna	Notas
id, nombre, codigo	Identidad y código opcional
id_mundo	FK → mundo(id)
orden, color	Orden en UI y color (por defecto #808080)
es_estado_final, es_importante, activo	Semántica de flujo de trabajo

Claves foráneas: fk_estados_mundo → mundo.

---

2.3workflow_version y workflow_version_estado

Instantáneas versionadas del grafo de workflow por mundo.

workflow_version

Columna	Notas
id_mundo	FK → mundo
version_number	Único por mundo (uq_mundo_version)
nombre, descripcion	Etiquetas opcionales
is_active	Si los informes nuevos pueden usar esta versión
created_at, created_by	Auditoría

workflow_version_estado

Columna	Notas
id_workflow_version	FK → workflow_version, borrado en CASCADE
id_estado	FK → estados
orden	Orden dentro de esa versión
es_estado_inicial, es_estado_final	Entrada y estados terminales
es_importante_snapshot	Importancia en el momento de crear la versión
nombre_snapshot, color_snapshot	Nombres y colores desnormalizados en el momento de la versión

Unicidad: (id_workflow_version, id_estado).

---

2.4informe_facturacion

Nueva cabecera de informe de facturación / workflow por instancia de compra (distinta de la tabla heredada reportefacturacion, que en ambos volcados sigue siendo mínima: Id, Flete).

Columna	Notas
id_instancia_compra	FK → clientes_instancia_compra, único (un informe por instancia)
id_estado	FK → estados, nullable
id_workflow_version	FK → workflow_version, nullable
created_by, updated_by	FK → Usuarios
created_at, updated_at	Marcas de tiempo

Incluye índice idx_informe_workflow sobre id_workflow_version.

---

2.5informe_estado_audit

Historial de auditoría de transiciones de estado en un informe.

Columna	Notas
id_informe	FK → informe_facturacion, CASCADE
from_estado_id, to_estado_id	IDs de estado
from_estado_nombre, to_estado_nombre, colores	Desnormalizado para el historial
changed_by	FK → Usuarios
changed_at, motivo	Cuándo y por qué

---

2.6alerts, alert_targets, alert_events, reglas

Alertas configurables en la aplicación (y opcionalmente por correo), con segmentación y reglas.

alerts

Columna	Notas
codigo	Clave de negocio única
titulo, descripcion, prioridad	Prioridad 1–4 según comentario en esquema
id_mundo	FK nullable → mundo (si es null, aplica a todos los mundos)
canal	Por defecto in_app; el comentario permite email / ambos
activo, orden	Activación y orden de presentación
created_at, created_by, updated_at	Auditoría

alert_targets

Vincula una alerta a roles o grupos funcionales:

• target_type: enum('role','functional_group')
• target_id, target_name, valor_original opcional
• Unicidad en (id_alert, target_type, target_id); FK a alerts con ON DELETE CASCADE

alert_events

Se registran cuando las reglas coinciden (transiciones de informe/estado):

• id_alert, id_informe, id_estado, triggered_at, payload JSON opcional
• FK a alerts con RESTRICT al borrar

reglas

• id_alert → alerts con CASCADE
• id_estado_trigger → estados con RESTRICT
• tipo_regla: entrada / salida (según comentario)
• condicion_json: JSON con condiciones

---

2.7user_notifications

Bandeja de notificaciones del usuario para varios tipos:

• notification_type: enum('message','reply','mention','alert','estado','folder_workflow')
• title, content, reference_id, reference_type, informe_id opcional
• is_read, metadata en JSON
• Índices: (user_id, created_at DESC), (user_id, is_read), informe_id

---

2.8folder_workflow_events

Registro de eventos de acciones sobre carpeta/workflow (auditoría, idempotencia):

• id_instancia_compra, informe_id opcional
• action_code, actor_user_id
• from_nivel / to_nivel, from_estado / to_estado
• cuadratura_before / cuadratura_after
• payload_json, idempotency_key (única cuando tiene valor)
• Índices por instancia y por (action_code, created_at)

---

2.9equipo_usuarios y relación con equipos

equipo_usuarios (muchos a muchos Usuarios ↔ equipos):

Columna	Notas
id_usuario	FK → Usuarios
id_equipo	FK → equipos
rol	Por defecto 'Miembro'
activo	Por defecto 1

En producción, equipos es una lista plana con id, Nombre, Estado; en desarrollo se añade la membresía sin cambiar la lista de columnas de equipos.

---

2.10push_subscriptions

Almacenamiento de suscripciones Web Push:

• endpoint, p256dh, auth (relacionados con VAPID)
• id_usuario → Usuarios con ON DELETE CASCADE
• created_at, last_used_at, user_agent

---

3Tablas existentes modificadas (diferencias de esquema)

3.1Usuarios

Cambio	Producción	Desarrollo
Columna nueva	—	Mundo varchar(1) DEFAULT 'N' — comentario: N=Nuevos, U=Usados, A=Ambos
Índice	—	KEY idx_usuarios_mundo (Mundo)

Interpretación: Los usuarios pueden quedar acotados a nuevos, usados o ambos, en línea con clientes_instancia_compra.Mundo.

---

3.2clientes_instancia_compra

Cambio	Producción	Desarrollo
Columna nueva	—	Mundo varchar(1) DEFAULT 'N' — comentario: N=Nuevos, U=Usados
Índice	—	KEY idx_instancia_mundo (Mundo)

El resto de columnas del volcado (hasta numerocredito) coinciden entre ambos archivos. Nota: el charset por defecto de la tabla sigue siendo swe7 en los dos dumps.

---

3.3Tablas sin cambios en la definición de columnas (listado de referencia)

Las siguientes aparecen estructuralmente iguales en los volcados (salvo ruido de AUTO_INCREMENT o comentarios del motor):
Stock_SAP, Stock_SIGA, accesorios, alertas, archivos, archivos_retoma, archivosfac, carpetas, cd_estados, clientes_hubspot, cod_modelos, comuna_cl, etiquetas, etiquetas_archivos, historial, log, marcas, metas_asesores, metasventa, modelos, provincia_cl, region_cl, reportefacturacion, subgerentejefeventa.

Los valores de AUTO_INCREMENT difieren entre volcados (normal al copiar subconjuntos de datos); por ejemplo carpetas e historial muestran contadores distintos en dev — no es un cambio de esquema.

---

4Vistas y rutinas

4.1Vistas solo en producción (definiciones completas en el volcado)

El volcado de producción termina con 14 definiciones de vista, entre ellas:

Vista	Propósito (según el SQL)
CARPETAS_FACTURADAS	Une clientes_instancia_compra, Usuarios, cod_modelos, Validaciones.Validaciones — carpetas facturadas filtradas
INSTANCIAS_NUEVOS	Nuevos del mes actual (excluye ciertos RUTs y lógica VU)
Instancias_usados	Filas recientes de usados
METAS_VENTAS_POR_MARCA	Paso directo sobre metasventa
VWEstadosCarpetasPorPeriodo	Agrega alertas por periodo
VWTIEMPOS_CARPETA	Usa calcular_horas_laborales, log, clientes_instancia_compra, Usuarios
VWUsuarios_inactivos	Vendedores sin clientes_instancia_compra
VW_CARPETAS_SIN_FACTURAR_POR_ASESOR	Construida sobre VW_RESUMEN_CARPETAS_DIGITALES
VW_INSTANCIAS	Instancia simplificada + equipo
VW_NOMBRES_CARPETAS	Lee Validaciones.NewTable
VW_REPORTES_DE_FACT_COMERCIAL	Reporte comercial de facturación
VW_RESUMEN_CARPETAS_ADHERENCIA	Resumen de adherencia (incluye Activo, concatenación de claves)
VW_RESUMEN_CARPETAS_DIGITALES	Core del resumen digital
VW_USUARIOS_CARPETA_DIGITAL	Lista de usuarios excluyendo IDs de sistema
VW_USUARIOS_CARPETA_DIGITAL_COMPLEMENTARIO	Usuarios con left join a Validaciones.Validaciones

4.2Volcado de desarrollo: conjunto de vistas

Solo dos vistas aparecen con cuerpo final CREATE VIEW:

1. CARPETAS_FACTURADAS — no equivale a producción. En desarrollo la definición es un marcador (placeholder):

   select 1 AS `Id_carpeta`, 1 AS `Rut`, ...  -- constantes literales
   

   Por tanto, cualquier reporte que dependiera de la vista real de producción no funcionaría con este volcado de dev sin restaurar la definición completa y los objetos de la base Validaciones.

2. vw_usuarios_equipos (nueva) — Une Usuarios, equipo_usuarios, equipos; expone usuario_id, nombres, email, nombre_equipo, rol, relacion_activa (desde equipo_usuarios.activo).

Consecuencia: El entorno de desarrollo o bien no depende de las vistas antiguas de BI, o las crea en otro sitio / no las vuelca. En la planificación de migraciones conviene tratar la paridad de vistas como un vacío explícito.

---

4.3Función almacenada (solo en producción)

calcular_horas_laborales(fecha_inicio, fecha_fin) — RETURNS int, DETERMINISTIC.
La usa VWTIEMPOS_CARPETA en producción. En el volcado de desarrollo no aparece.

---

5Dependencias externas / entre bases de datos

Las vistas de producción referencian:

• Validaciones.Validaciones — metadatos ERP/usuario (AREA_VENDEDOR, CIUDAD, etc.)
• Validaciones.NewTable — VW_NOMBRES_CARPETAS

La CARPETAS_FACTURADAS real en producción usa ese join. El stub de desarrollo lo evita pero pierde toda la semántica.

---

6Indicadores de volumen de datos (AUTO_INCREMENT en los volcados)

No son cambios de esquema, pero ayudan a dimensionar el dataset en cada volcado:

Tabla	AI prod. (aprox.)	AI dev (aprox.)
Usuarios	1522	1477
carpetas	609066	578172
clientes_instancia_compra	35000	33576
equipos	1022	64

La caída fuerte del AI de equipos en dev sugiere un catálogo de equipos más pequeño o resembrado, mientras que equipo_usuarios enlaza usuarios con esos equipos.

---

7Modelo conceptual de lo añadido en desarrollo

---

8Recomendaciones de seguimiento

1. Restaurar o redefinir en desarrollo las vistas de producción si se necesita paridad con BI/reporting — en especial lo que use Validaciones y calcular_horas_laborales.
2. Sustituir el stub de CARPETAS_FACTURADAS en dev por la vista real o documentar que el entorno de desarrollo omite a propósito el reporting entre bases.
3. Alinear versiones de MySQL (8.0.44 vs 8.4.7) en CI o staging si se depende de comportamiento específico de versión.
4. El código que trate Estado como entero suelto debe convivir o reconciliarse con la nueva tabla estados y el flujo informe_facturacion — los volcados muestran ambos mundos coexistiendo (clientes_instancia_compra.Estado sigue siendo int).

---

Documento generado a partir del análisis estático de dump-CarpetaDigital.sql y dump-CarpetaDigital_dev.sql (marcas de tiempo del volcado: 2026-03-31).