Saltar a contenido
v26.3

Base de datos (CouchDB / SQLite / SQL Server)

DiKAS admite tres proveedores de base de datos. El proveedor se configura en appsettings.json (Database.Provider) o mediante variables de entorno; el código es idéntico y todas las funciones están disponibles con cualquier proveedor.

Proveedor Uso
CouchDb (estándar) Funcionamiento servidor/nube, multiinquilino, replicación
Sqlite Puesto individual, app de Android, demo/desarrollo
SqlServer Infraestructura Microsoft existente

Configuración

{
  "Database": { "Provider": "CouchDb" },
  "CouchDb": {
    "ServerUrl": "http://localhost:5984",
    "DatabasePrefix": "dikas",
    "MainDatabase": "main"
  }
}

Las variables de entorno sobrescriben el archivo, práctico para Docker y pruebas:

Variable Significado
Database__Provider CouchDb, Sqlite o SqlServer
COUCHDB_URL URL del servidor, p. ej. http://192.168.1.10:5984
COUCHDB_USER / COUCHDB_PASSWORD Credenciales de acceso
COUCHDB_PREFIX Prefijo de base de datos (único por instalación/inquilino)

En el primer inicio, DiKAS crea automáticamente las bases de datos ({prefix}_maindb, {prefix}_gastrocurrent), el documento de diseño con todas las vistas y —en una base de datos vacía— los datos de demostración.

Datos de demostración e historial

  • Auto-Seed: Una base de datos vacía (SQLite o CouchDB) se rellena al iniciar con datos maestros de demostración (artículos, personal, mesas, clientes).
  • Generar historial (para pruebas/análisis):
dotnet run --project Dikas.Api.Web -- --seed-history 730

genera comprobantes, turnos y cierres de caja realistas para el número de días indicado (tasa de escritura masiva ≈ 760 documentos/s). Los números de comprobante/turno/cierre se continúan, y el funcionamiento corriente enlaza sin interrupciones.

Rendimiento (CouchDB)

Los principales parámetros de ajuste de la prueba de carga con 2 años de historial (34.500 comprobantes):

  • Rango de fechas en lugar de exploración completa: Todos los informes y consultas operativas cargan los comprobantes a través de la vista bybizdate_docs (rango de días comerciales). Los periodos cortos son así rápidos con independencia del tamaño de la base de datos.
  • Ventas diarias precondensadas: La vista Map/Reduce revenue_daily suma bruto/impuesto/número de comprobantes por día directamente en CouchDB. El endpoint GET /api/v1/reports/daily-aggregate?startDate=…&endDate=… entrega 2 años de ventas diarias en ~0,1 s, ideal para paneles.
  • Registro de consultas lentas: Los accesos a vistas que superan 1 s aparecen como Warning en el registro (vista, número de filas, duración, URL) y muestran de inmediato las consultas costosas.
  • Mantenimiento: Tras grandes importaciones de datos, planifique _compact y _view_cleanup: las vistas de documentos mantienen una copia de los comprobantes en el índice (memoria a cambio de velocidad).

Sincronización con la nube

Las instalaciones locales pueden sincronizarse con la CouchDB central en la nube. La conexión se resuelve automáticamente desde la licencia (systemlic) al iniciar el servidor: usuario = SyncLink (en minúsculas), contraseña = SyncLink, base de datos remota = {DatabaseName}_{db}. Una sección Sync rellenada manualmente en appsettings.json prevalece sobre la licencia. Gestión y estado: Admin → Configuración → Sistema → Cloud-Sync (inicio de sesión de soporte).

Modo Mecanismo
CouchDb (local) Replicación nativa de CouchDB: entradas push+pull continuas en _replicator para {prefix}_maindb y {prefix}_gastrocurrent (patrón de ID {prefix}_{db}_push / _pull)
Sqlite / SqlServer Servicio de sincronización propio: push/pull de tipos de documento seleccionados a intervalos (conflictos: gana la última escritura)
Cloud multiinquilino Sin sincronización: los dispositivos trabajan directamente sobre la base de datos central

Al configurar la replicación nativa se eliminan las entradas _replicator obsoletas que apuntan a las mismas bases de datos pero ya no se corresponden con la configuración actual (p. ej. tras cambiar SyncLink o el nombre de la base de datos). Si falta SyncLink en la licencia, se eliminan las propias entradas: la replicación queda entonces desactivada. El estado del trabajo (_scheduler/docs) se muestra en la página de Cloud-Sync; en caso de errores de conexión, el servidor intenta la configuración de nuevo cada 5 minutos.

Notas sobre SQLite

  • Archivo de base de datos: Dikas.Api.Web/dikas.db (en la raíz de contenido, independiente del directorio de trabajo).
  • Las migraciones de esquema se ejecutan automáticamente al iniciar (EF Core).
  • Para migrar a CouchDB: cree una copia de seguridad y restáurela en una instalación de CouchDB (consulte Copia de seguridad y restauración).