Files
project.linkedcorp.net/BASE_DE_DATOS.md
T
Milton Gonzalez 1d22adc42e chore: estructura inicial del MVP
Backend (Express + MariaDB) y frontend (React + Vite, identidad Fluent/Windows) con el
nucleo funcional: seguridad, organizacion, proyectos, actividades, subtareas, dependencias,
dashboard, calendario, gantt, comentarios, adjuntos, notificaciones in-app y catalogos.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-09-03 08:37:58 -05:00

5.8 KiB

Base de Datos - project.linkedcorp.net

Motor

  • Motor: MariaDB
  • Base principal: project_linkedcorp
  • Host desarrollo: 192.168.222.20
  • Host producción: 192.168.222.32
  • Puerto: 3306
  • Charset: utf8mb4
  • Collation: utf8mb4_unicode_ci

Fuente de verdad

  • La base ya existe: sí (creada en dev el 2026-09-03, usuario project_linkedcorp).
  • Archivo SQL base: backend/database/migrations/ (SQL idempotente, numerado, CREATE TABLE IF NOT EXISTS).
  • Seeds: backend/database/seeds/ (roles, catálogos, usuario admin de dev).

Tablas principales (MVP)

Tabla Contenido
roles catálogo fijo de 5 roles (admin, it_manager, project_lead, collaborator, viewer)
users usuarios, con rol y departamento
departments departamentos/áreas, jerarquía simple vía parent_id
project_types catálogo de tipos de proyecto
priorities catálogo de prioridades (baja/media/alta/crítica)
project_statuses catálogo de estados de proyecto
activity_statuses catálogo de estados de actividad
projects proyectos
project_members usuarios asignados a un proyecto (reemplaza "equipos" como módulo aparte)
activities actividades de un proyecto
activity_dependencies dependencias simples entre actividades ("depende de")
subtasks checklist liviano dentro de una actividad
comments comentarios sobre proyecto o actividad (entity_type + entity_id)
attachments archivos adjuntos a proyecto o actividad
notifications notificaciones in-app por usuario
audit_log auditoría central (quién, qué, sobre qué, cuándo)

Relaciones clave

  • users.role_id -> roles.id, users.department_id -> departments.id
  • departments.parent_id -> departments.id (jerarquía opcional, ej. TI → Desarrollo)
  • projects.status_id -> project_statuses.id, projects.priority_id -> priorities.id, projects.project_type_id -> project_types.id, projects.owner_user_id -> users.id, projects.requesting_department_id / responsible_department_id -> departments.id
  • project_members.project_id -> projects.id, project_members.user_id -> users.id
  • activities.project_id -> projects.id, activities.status_id -> activity_statuses.id, activities.priority_id -> priorities.id, activities.responsible_user_id -> users.id
  • activity_dependencies.activity_id / depends_on_activity_id -> activities.id
  • subtasks.activity_id -> activities.id, subtasks.responsible_user_id -> users.id (nullable)
  • comments.entity_id / attachments.entity_id apuntan a projects.id o activities.id según entity_type (sin FK física cruzada — se valida en el servicio)

Reglas de datos

  • projects.progress_pct y activities.progress_pct son calculados por el servicio, no editables directo por el cliente: actividad con subtareas = % de subtareas hechas; actividad sin subtareas = manual (0-100); proyecto = promedio del avance de sus actividades.
  • users.password_hash con bcrypt, nunca texto plano ni reversible.
  • Borrado lógico donde aplique (users.is_active); nunca DELETE físico de usuarios con historial.
  • Empresa asumida única (no hay tabla companies en el MVP).
  • Producción siempre usa 192.168.222.32. Desarrollo siempre usa 192.168.222.20. No mezclar.

Riesgos o decisiones

  • Sin triggers de BD para recalcular avances: toda la lógica vive en la capa service/ del backend (más simple de depurar y de extender en fase 2).
  • risk_level es un campo simple en projects (bajo/medio/alto) — el módulo completo de Riesgos (probabilidad/impacto/mitigación) queda para fase 2, sin necesitar migrar este campo.

Archivos relacionados

  • backend/.env.example
  • backend/database/migrations/*.sql
  • backend/database/seeds/*.sql

Crear la base de datos en DESARROLLO (.20)

Ya ejecutado para este proyecto (2026-09-03):

bash /home/mgonzalez/desarrollo/project-md-templates/crear-db-dev.sh project_linkedcorp project_linkedcorp

BD project_linkedcorp y usuario project_linkedcorp@192.168.222.40 creados en 192.168.222.20. Las credenciales están en backend/.env (no versionado).

Verificar:

mysql --defaults-extra-file=~/.config/mysql/dev20-admin.cnf -e "SHOW DATABASES LIKE 'project_linkedcorp';"

Aplicar migraciones/seeds (una vez creado backend/src/scripts/migrate-db.js):

cd backend
set -a && source .env && set +a
node src/scripts/migrate-db.js
node src/scripts/seed-db.js

Setup de base de datos en producción (primera vez) — pendiente, no ejecutado aún

El servidor .32 no tiene SSH accesible; el acceso admin es solo desde la máquina de desarrollo. Credenciales de acceso admin: ver SERVIDORES.md (project-md-templates/, no versionado).

mysql -h 192.168.222.32 -u mgonzalez -p --ssl=0
CREATE DATABASE IF NOT EXISTS project_linkedcorp
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;

CREATE USER IF NOT EXISTS 'project_linkedcorp'@'192.168.222.3'
  IDENTIFIED BY '[DB_PASSWORD_PROD]';

GRANT ALL PRIVILEGES ON project_linkedcorp.* TO 'project_linkedcorp'@'192.168.222.3';

FLUSH PRIVILEGES;

Migración en el servidor de aplicaciones (.3), cuando exista el deploy:

ssh deploy@192.168.222.3 -p 2203
cd /opt/apps/project.linkedcorp.net/source/backend
set -a && source /opt/apps/project.linkedcorp.net/backend/.env && set +a
node src/scripts/migrate-db.js
node src/scripts/seed-db.js   # solo catálogos/roles; NO recrear usuarios de prueba de dev

Actualizaciones de esquema en producción

Método: archivos SQL idempotentes en backend/database/migrations/00X-nombre.sql (CREATE TABLE IF NOT EXISTS / information_schema guards), aplicados con node src/scripts/migrate-db.js. Siempre backup (mysqldump --single-transaction) antes de migrar en producción.