Una aplicación de gestión había crecido alrededor de una regla sencilla: cada mascota pertenecía a una sola tienda. Con el tiempo, los clientes empezaron a utilizar distintos centros y esa regla dejó de representar la realidad. La petición parecía pequeña —«queremos asignar varias tiendas»—, pero afectaba a calendarios, guardería, residencia, bonos, permisos y sincronizaciones externas.
La solución fácil habría creado problemas nuevos
Duplicar la mascota en cada tienda habría sido rápido, pero habría fragmentado el historial. El mismo microchip podría aparecer varias veces, las reservas quedarían repartidas y una actualización no sabría qué registro era el correcto.
Por eso mantuve una mascota única y añadí una relación independiente entre mascotas y tiendas. La columna antigua se conserva como tienda principal para que el código histórico siga funcionando.
Reglas que debía respetar el nuevo modelo
- Una mascota puede estar visible en varias tiendas.
- No se duplican historiales ni identificadores externos.
- Solo se pueden asignar tiendas que también tenga su propietario.
- Un empleado solo puede asignar centros que tenga permiso para gestionar.
- El alta y la edición se guardan en una única transacción.
- Cada cambio de asignación queda auditado.
Compatibilidad antes que reescritura
Una aplicación en producción no puede detenerse mientras se adapta cada pantalla. Incorporé una capa de compatibilidad: si una mascota antigua todavía no tiene relaciones explícitas, el sistema utiliza su tienda principal. Esto permitió actualizar módulos progresivamente sin dejar datos invisibles.
Después revisé los puntos donde se filtran mascotas: listados de clientes, calendarios, servicios, bonos y operaciones internas. El cambio de base de datos era solo el principio; el verdadero trabajo estaba en mantener un criterio único de visibilidad.
Qué aprendí de esta evolución
Cuando un negocio crece, las relaciones que parecían «uno a uno» suelen transformarse. Conviene evitar que una decisión inicial quede repartida por decenas de consultas sin una capa de dominio. Centralizar la lectura de permisos y pertenencias reduce muchísimo el riesgo de futuras ampliaciones.
También es importante diseñar la migración para convivir con datos antiguos. Una evolución profesional no obliga a duplicarlo todo ni a reconstruir de golpe el sistema.