Volver al inicio

Geoorganizer: modelo de datos y sincronización

Personal Geoorganizer utiliza un modelo con Puntos atómicos, Lugares, Rutas y Carpetas jerárquicas. Sincronización vía dirty tracking y solicitudes por lotes asegura reactividad. Adecuado para desarrolladores intermedios/senior, stack: PHP, Vue 3, MariaDB.

Construye un Geoorganizer: desde el modelo hasta la sincronización
Advertisement 728x90

Arquitectura de un Organizador Personal de Geodatos: Modelo y Sincronización

Un organizador personal de geodatos aborda el desafío de estructurar datos espaciales personales mediante un modelo de entidades claro. Los componentes clave incluyen: Punto como geometría atómica, Lugar con metadatos, Ruta como secuencia de puntos y Carpeta para jerarquía. Esta estructura permite construir árboles de objetos sin duplicar coordenadas, garantizando reactividad en la interfaz.

Los Puntos almacenan solo latitud, longitud, altitud y un UUIDv4. Son independientes de otras entidades y sirven como elementos de referencia. Cada Lugar referencia un único Punto por ID, añadiendo nombre, descripción, álbumes de fotos y enlaces. Las Rutas contienen una lista ordenada de IDs de puntos, admitiendo repeticiones para escenarios no lineales. Las Carpetas organizan Lugares y Rutas en árboles con campos parent, context y srt para ordenación.

Entidades en Detalle

Punto

Geometría pura sin contexto. Almacenado como binary(16) en MariaDB/MySQL para optimización de índices. Las referencias a él son cadenas UUIDv4 en el frontend.

Google AdInline article slot

Lugar

Metadatos adjuntos a un Punto. Ejemplo: un ID de Punto con una descripción como "Glorieta para la primera cita" y un álbum de fotos. La posición en el árbol se determina por folderid.

Ruta

Secuencia de IDs de Punto con metadescripciones. Un solo Punto puede repetirse, adecuado para bucles o retornos. Ejemplo: ruta "Paseo nocturno" — casa → tienda → parque (múltiples puntos) → biblioteca → casa.

Carpeta

Estructura de árbol con campos id, parent, srt (fraccional para orden), context (places o routes). El árbol se construye de forma reactiva desde una lista plana.

Google AdInline article slot

Tecnologías y Base de Datos

Backend en PHP, frontend — Vue 3 con Composition API, TypeScript, Pinia y Axios. Base de datos — MariaDB/MySQL. Entidades en tablas points, places, routes, folders.

Característica clave — atomicidad de los Puntos: no conocen a sus consumidores, minimizando duplicación y simplificando actualizaciones.

Sincronización de Cambios

El cliente rastrea estados sucios de objetos con banderas added, updated, deleted en el almacén Pinia. Objeto de ejemplo:

Google AdInline article slot
{
	"id": "e7c6c8c4-4e3b-4d2f-8b61-8c9eaa2c1d51",
	"title": "Glorieta",
	"pointid": "a2c17b8f...",
	"added": false,
	"updated": true,
	"deleted": false
}

Filtrado antes de enviar: solo objetos cambiados, excluyendo added+deleted en la misma sesión.

Envío por Lotes al Servidor

El botón "Guardar" forma una única solicitud con un lote:

{
	"userid": "...",
	"sessionid": "...",
	"data": {
		"points": [...],
		"places": [...],
		"routes": [...],
		"folders": [...]
	}
}

El servidor aplica operaciones en orden: DELETE > INSERT > UPDATE, como una mini-transacción.

Ventajas de este enfoque:

  • Número mínimo de solicitudes — un lote por serie de ediciones.
  • Interfaz reactiva: trabajar con una copia local de datos.
  • Simplicidad del servidor: un endpoint sin múltiples rutas.
  • Escalabilidad: nuevas entidades añadidas al lote sin cambios de protocolo.

Conclusiones Clave

  • Los Puntos atómicos garantizan integridad referencial sin duplicar geodatos.
  • El modelo de árbol mediante Carpetas se construye de forma reactiva en el frontend.
  • El rastreo de cambios sucios + sincronización por lotes reducen la carga de red.
  • La pila (PHP/Vue 3/Pinia/MariaDB) equilibra simplicidad y rendimiento.
  • Proyecto de código abierto en GitHub con demo bajo test/test.

— Editorial Team

Advertisement 728x90

Leer después