Su operación en una sola base de datos

Cada cliente, su propia base

Los datos de cada cliente viven en su propia base de datos, dentro de su propio contenedor, en una red interna que no toca internet. No es una separación por carpetas dentro de un sistema compartido, ni una columna «cliente_id» que alguien puede olvidar filtrar.

• La base no está en la red que recibe tráfico de fuera. El túnel que sirve la web no puede verla ni por nombre.
• El día que quiera llevarse su base, se entrega entera y sin filtrar nada, porque dentro no hay datos de nadie más.
• Lo que registramos de nuestra propia operación está en otro sistema y no se entrega con ningún proyecto.

La base impide guardar cosas imposibles

Lo habitual es validar en la aplicación. Eso funciona hasta que un segundo proceso escribe — una importación, un bot, alguien con acceso directo — y entonces entran datos que la aplicación jamás habría aceptado. Aquí las reglas viven en la base, así que se cumplen escriba quien escriba.

• Una cita para un profesional que no existe no se puede guardar: el nombre es una llave foránea, no un texto libre.
• Un índice único sobre profesional, fecha y franja impide agendar dos veces el mismo hueco — y hace que volver a cargar la agenda no duplique una sola fila.
• Un lead de formulario no entra sin nombre, sin correo y sin la autorización con su fecha y hora. La regla es de la base, no de una casilla del navegador.
• Los importes se declaran con el tipo que conserva la precisión, no como número flotante que redondea a espaldas de todos.

Cada proceso entra con los permisos mínimos

Los permisos no se dan por tabla sino por columna. Suena a exceso hasta que se piensa qué puede hacer un asistente automático el día que alguien le escriba algo raro.

• El asistente que atiende WhatsApp puede anotar una cita y no puede releer una sola conversación que él mismo escribió.
• Puede escribir en cuatro columnas de una tabla y no en las demás. No es que la aplicación se lo impida: es que la base se lo niega.
• Los permisos se vuelven a aplicar en cada arranque, porque rehacer una vista los borra en silencio y ese es exactamente el fallo que nadie nota hasta que algo deja de funcionar.

El esquema es un fichero, no una serie de cambios a mano

La estructura completa de la base vive en un fichero versionado y se aplica entera en cada arranque. Se puede leer, revisar y comparar con lo que había hace un mes. Nadie «se acuerda» de qué se cambió.

• Aplicarlo dos veces no cambia nada: está escrito para poder repetirse.
• Levantar una copia idéntica en limpio es un comando, no una tarde.
• Las consultas nunca se arman pegando texto. Los valores viajan como parámetros, que es lo que hace que un dato con una comilla no pueda convertirse en una instrucción.

Y hay copias, probadas restaurándolas

Una copia de seguridad que nadie ha restaurado nunca es una suposición. La de aquí se restauró de verdad: se borró la local, se bajó la de fuera, se descifró y se cargó en una base limpia y aislada para comprobar que estaba completa.

• Copia diaria y automática, cifrada antes de salir del servidor.
• Siete copias en el servidor y treinta fuera, con otro proveedor.
• Si la copia falla avisa; y si deja de ejecutarse, también — que es el fallo que de verdad pasa desapercibido.

Se puede enseñar funcionando

Nada de lo anterior es una promesa de folleto: cada punto corresponde a una decisión concreta y se puede ver corriendo. Si está evaluando a quién le entrega los datos de su empresa, pida ver esto — a nosotros o a quien sea.