返回首页

Geoorganizer:数据模型和同步

个人 Geoorganizer 使用具有原子 Points、Places、Routes 和层次 Folders 的模型。通过脏标记和批量请求的同步确保响应性。适用于中高级开发者,技术栈:PHP、Vue 3、MariaDB。

构建 Geoorganizer:从模型到同步
Advertisement 728x90

个人地理数据组织器架构:模型与同步机制

个人地理数据组织器通过清晰的实体模型解决个人空间数据的结构化难题。核心组件包括:作为原子几何单元的“点”、附带元数据的“地点”、由点序列构成的“路线”,以及用于层级管理的“文件夹”。这种结构能够构建对象树而不重复坐标,确保界面响应性。

点仅存储纬度、经度、海拔和UUIDv4标识符,独立于其他实体,作为引用元素。每个地点通过ID引用单个点,并添加名称、描述、相册和链接。路线包含有序的点ID列表,支持重复以应对非线性场景。文件夹将地点和路线组织成树状结构,包含父级、上下文和排序字段。

实体详解

纯几何数据,无上下文信息。在MariaDB/MySQL中以binary(16)存储以优化索引。前端通过UUIDv4字符串引用。

Google AdInline article slot

地点

附加到点的元数据。例如:一个点ID附带“首次会面的凉亭”描述和相册。在树中的位置由文件夹ID决定。

路线

点ID序列及元描述。单个点可重复出现,适用于循环或往返场景。示例:“晚间散步”路线——家→商店→公园(多点)→图书馆→家。

文件夹

树状结构,包含ID、父级、排序字段(用于顺序)和上下文(地点或路线)。树从扁平列表反应式构建。

Google AdInline article slot

技术栈与数据库

后端使用PHP,前端采用Vue 3组合式API、TypeScript、Pinia和Axios。数据库为MariaDB/MySQL。实体存储于points、places、routes、folders表。

关键特性——点的原子性:它们不感知使用者,最小化重复并简化更新。

变更同步

客户端通过Pinia存储中的added、updated、deleted标志跟踪对象的脏状态。示例对象:

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

发送前过滤:仅包含变更对象,排除同一会话中新增又删除的项。

批量发送至服务器

“保存”按钮形成包含批次的单一请求:

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

服务器按顺序应用操作:DELETE > INSERT > UPDATE,作为迷你事务。

此方法的优势:

  • 请求数量最少——每轮编辑仅一个批次。
  • 响应式用户界面:基于本地数据副本操作。
  • 服务器简化:单一端点,无需多路由。
  • 可扩展性:新实体可加入批次而无需协议变更。

核心要点

  • 原子点确保引用完整性,避免地理数据重复。
  • 通过文件夹的树模型在前端反应式构建。
  • 脏跟踪+批量同步降低网络负载。
  • 技术栈(PHP/Vue 3/Pinia/MariaDB)平衡简洁性与性能。
  • GitHub开源项目,演示位于test/test。

— Editorial Team

Advertisement 728x90

继续阅读