Relacionar tablas

Una relación evita que escribas lo mismo dos veces. En vez de teclear "Pastelería" en cada producto, guardas a qué categoría apunta; si mañana cambias el nombre de la categoría, cambia en todos lados.

El problema que resuelve

Sin relaciones, tendrías que copiar el nombre del cliente en cada pedido:

Pedido #1: Cliente "María González", teléfono "+56 9 8123 4567"
Pedido #2: Cliente "María González", teléfono "+56 9 8123 4567"
Pedido #3: Cliente "María González", teléfono "+56 9 8123 4567"

Si María cambia de teléfono, tienes que actualizar los tres pedidos. Con miles de registros se vuelve un caos.

Con una relación, guardas al cliente una vez en la tabla Clientes, y cada pedido solo apunta a él. Cambias el teléfono una vez y listo.

Crear una relación en 3 pasos

1. En la columna que quieres relacionar, elige el tipo Relaciones.
2. Aparece el campo Parámetro del tipo. Escribe ahí el nombre de la tabla relacionada, tal cual: categorias.
3. Guarda. En el formulario de alta, esa columna se convierte en una lista desplegable con los registros reales de esa tabla.

Qué se muestra en el desplegable

Por defecto, se muestra la segunda columna de la tabla relacionada (el sistema asume que la primera es el ID y la segunda suele ser el nombre).

Si quieres mostrar una columna específica, usa el formato tabla:columna en el parámetro:

• categorias → muestra la segunda columna (típicamente "nombre").
• clientes:email → muestra la columna "email" de cada cliente.
• ventas:fecha_venta → muestra la fecha en el desplegable.

Cómo se ve en el listado

Se muestra el nombre del registro relacionado, no un ID críptico. Ejemplo:

ID	Cliente	Producto	Cantidad
1	Valentina Pérez	Café Americano	2
2	Diego Fuentes	Torta de Chocolate	1

Al hacer clic en "Valentina Pérez", te lleva a su ficha completa en Clientes.

:::warning Crea primero la tabla "de destino" Para que productos pueda apuntar a categorias, la tabla categorias tiene que existir antes. Por eso conviene crear primero las listas simples (categorías, servicios, unidades) y después las que las usan (productos, pedidos, visitas). :::

Relacionar con usuarios (admins)

Si quieres que una columna apunte a un administrador del sistema (por ejemplo, "vendedor asignado", "supervisor de la visita"):

• Tipo: Relaciones.
• Parámetro: admins.

El desplegable te dejará elegir entre los usuarios del CMS. En el listado se muestra el nombre del admin, enlazado a su ficha.

:::note Seguridad El sistema usa un select acotado para admins — nunca expone el hash de la contraseña ni datos sensibles. :::

Relaciones opcionales vs obligatorias

Como cualquier otro campo, puedes marcar la columna como:

• Requerido: el usuario debe elegir un valor antes de guardar.
• No requerido: puede dejarse vacío.

Relaciones múltiples (muchos a muchos)

El framework maneja de forma nativa "un registro apunta a otro" (muchos-a-uno). Por ejemplo, muchos pedidos apuntan a un mismo cliente.

Para casos muchos-a-muchos (un pedido tiene varios productos, un producto está en varios pedidos), la manera limpia es crear una tabla intermedia:

Tabla Pedidos                (pedido base)
Tabla Productos              (catálogo)
Tabla Lineas de pedido       (línea de detalle)
   ├── pedido:    → Pedidos
   ├── producto:  → Productos
   ├── cantidad:  Entero
   └── precio_unitario: Moneda

Cada fila de "Líneas de pedido" es una línea con su producto, cantidad y precio.

Este patrón es el que usa el POS Manager automáticamente al crear una venta.

Filtrar el listado por relación

En cualquier listado, los campos de relación aparecen como filtros. Ejemplo: en el listado de Pedidos puedes filtrar "Todos los pedidos del cliente Valentina Pérez" con un clic.

Vistas (VIEWs) de la base de datos

Además de tablas, el framework también reconoce vistas de MySQL. Si un desarrollador crea una vista curada (por ejemplo, "productos_activos_con_stock"), aparece en el selector al crear páginas públicas.

Útil cuando quieres:

• Mostrar solo un subconjunto (productos activos).
• Precalcular totales.
• Combinar varias tablas en una vista única.

Errores comunes

• Apuntar a una tabla que no existe todavía. Crea primero la tabla destino.
• Borrar un registro que tiene relaciones. Los que apuntan quedan huérfanos. Considera desactivar en vez de borrar.
• Guardar el nombre como texto en vez de relación. Después no puedes filtrar bien ni actualizar en cascada.

¿Qué sigue?

• Campos condicionales — mostrar campos según el valor de otros.
• Importar y exportar datos — mover información masivamente.
• Flujos de trabajo — controlar cambios de estado.