Base principal

Fuente de verdad

PostgreSQL guarda permanentemente todo lo que importa: catálogo, inventario, compras, ventas y los comprobantes. Es la única "verdad" del sistema; todo lo demás (la memoria rápida, el buscador) es caché o se deriva de aquí. En realidad son 3 bases separadas en el mismo servidor — esta página describe la principal (leon_principal); las otras dos, en Las tablas del negocio.

Esta página describe el componente. El detalle de cada tabla, campo por campo, vive en el modelo oficial: Las tablas del negocio →

¿Qué es?

Una base de datos relacional PostgreSQL. Cada lectura y escritura del motor pasa por aquí. Guarda el catálogo (producto, variante), el inventario, las compras de importación, las ventas y —sobre todo— los comprobantes electrónicos, que son legales y no pueden vivir en ningún sitio temporal.

Qué guarda

Las tablas reales, en español y con el dominio del negocio. El esquema completo está en el modelo oficial; aquí va el mapa de alto nivel:

Catálogo: producto, variante (el SKU vive aquí), categoria, imagen_producto.

Inventario: almacen y movimiento_inventario. El stock no es una columna: se calcula sumando los movimientos.

Compras / importación: proveedor, orden_compra, embarque, costo_importacion, documento_aduanero, muestra.

Ventas: cliente, pedido, linea_pedido, envio_cliente.

Facturación: comprobante, nota_credito, pago. Lo legal: serie/correlativo, estado SUNAT, XML/CDR.

Equipo: usuario, con su rol.

Por qué el stock se calcula

Una columna stock escrita a mano se desincroniza en cuanto dos operaciones la tocan a la vez. En su lugar, cada entrada (compra) y cada salida (venta) se anota como una fila en movimiento_inventario, y el stock disponible es la suma. Así siempre cuadra y queda auditable: se puede reconstruir de dónde salió cada unidad.

Lo que garantiza

Transacciones (ACID): si una operación falla a mitad, se deshace entera. Nunca queda un pedido sin su línea ni un cobro a medias.

Integridad referencial: las llaves foráneas impiden datos huérfanos (una línea de pedido siempre apunta a una variante que existe).

Índices: búsquedas rápidas por SKU, por documento de cliente, por pedido.

Comprobantes: se guardan aquí para siempre, nunca en la memoria rápida.

Respaldos: con pg_dump, hoy manual — no hay un cron ni una tarea automática de backup diario configurada todavía. Procedimiento en Despliegue y mantenimiento.

Para más adelante Fase posterior

Nada de esto hace falta para el piloto (30–50 SKU). Se difiere hasta que el volumen lo justifique:

Réplica en standby y failover: una segunda copia que toma el relevo si el servidor principal cae. Útil cuando una caída cueste dinero por minuto; al inicio, el respaldo diario basta.

Particionamiento / sharding: repartir tablas enormes entre servidores. Solo tiene sentido con millones de filas.

Réplicas de lectura: servidores extra solo para reportes pesados. Más tarde.

Stack

PostgreSQL 16 Django ORM SQL a mano (sin migraciones) pg_trgm (búsqueda) pg_dump (respaldo)

Por qué: PostgreSQL es robusto y maneja bien lo relacional. El ORM de Django lee y escribe sin SQL a mano en el día a día, pero el esquema no lo versionan migraciones de Django: todos los modelos de negocio son managed=False y el esquema real vive en archivos .sql versionados en un repositorio aparte, aplicados directamente con psql. Cambiar una tabla es editar ese SQL y aplicarlo a mano, no makemigrations. La extensión pg_trgm, dentro de la misma base, cubre la búsqueda —no hace falta un buscador aparte.

La base de datos es el bien más valioso del negocio: respaldo y monitoreo son innegociables. Tres reglas sostienen el modelo —el SKU vive en la variante, el stock se calcula sumando movimientos, y los comprobantes se guardan permanentemente aquí. El detalle campo por campo está en el modelo oficial.