Saltar a contenido
v26.3

Base de datos (CouchDB / SQLite)

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

SQL Server ya no es compatible

Las versiones anteriores de esta página incluían un tercer proveedor, SqlServer. Solo se admiten CouchDb y Sqlite.

Configuración

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

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

Variable Significado
Database__Provider CouchDb, Sqlite
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 En el modo de replicación, SQLite sincroniza los datos y las eliminaciones con la nube; los cambios simultáneos se resuelven según su fecha de modificación. Las instalaciones existentes pueden seguir usando la sincronización anterior de tipos de documento seleccionados. Soporte comprueba el modo antes de cambiarlo.
Cloud multiinquilino Sin sincronización: los dispositivos trabajan directamente sobre la base de datos central

Después de restaurar la base de datos de la nube, soporte debe comprobar que la sincronización esté completa en ambas direcciones. Hasta entonces, un estado aparentemente normal no demuestra la integridad. No elimine los datos locales.

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).