Geoorganizator: model danych i synchronizacja

Architektura osobistego organizatora danych geograficznych: model i synchronizacja

Osobisty organizator danych geograficznych rozwiązuje problem strukturyzacji osobistych danych przestrzennych poprzez klarowny model encji. Główne komponenty: Punkt jako atomowa geometria, Miejsce z metadanymi, Trasa jako sekwencja punktów oraz Folder do hierarchii. Ta struktura pozwala budować drzewa obiektów bez duplikowania współrzędnych, zapewniając reaktywność interfejsu.

Punkty przechowują tylko szerokość, długość, wysokość i UUIDv4. Nie zależą od innych encji i służą jako elementy referencyjne. Każde Miejsce odnosi się do jednego Punktu przez ID, dodając nazwę, opis, albumy zdjęć i linki. Trasy zawierają uporządkowaną listę ID punktów, obsługując powtórzenia dla nieliniowych scenariuszy. Foldery organizują Miejsca i Trasy w drzewa z polami parent, context i srt do sortowania.

Encje szczegółowo

Punkt

Czysta geometria bez kontekstu. Przechowywana jako binary(16) w MariaDB/MySQL dla optymalizacji indeksów. Odwołania do niej – ciągi UUIDv4 na froncie.

Miejsce

Metadane przypisane do Punktu. Przykład: ID Punktu z opisem „Altanka na pierwsze spotkanie” i albumem zdjęć. Pozycja w drzewie określana przez folderid.

Trasa

Sekwencja ID Punktów z metaopisami. Jeden Punkt może się powtarzać, co pasuje do pętli lub powrotów. Przykład: trasa „Wieczorny spacer” – dom → sklep → park (kilka punktów) → biblioteka → dom.

Folder

Struktura drzewiasta z polami id, parent, srt (ułamkowe dla kolejności), context (places lub routes). Drzewo budowane reaktywnie z płaskiej listy.

Stos technologiczny i baza danych

Backend w PHP, frontend – Vue 3 z Composition API, TypeScript, Pinia i Axios. Baza – MariaDB/MySQL. Encje w tabelach points, places, routes, folders.

Kluczowa cecha – atomowość Punktów: nie znają konsumentów, co minimalizuje duplikaty i upraszcza aktualizacje.

Synchronizacja zmian

Klient śledzi dirty-stan obiektów flagami added, updated, deleted w Pinia-store. Przykład obiektu:

{
	"id": "e7c6c8c4-4e3b-4d2f-8b61-8c9eaa2c1d51",
	"title": "Altanka",
	"pointid": "a2c17b8f...",
	"added": false,
	"updated": true,
	"deleted": false
}

Filtracja przed wysłaniem: tylko zmienione, wykluczając added+deleted w jednej sesji.

Pakietowe wysyłanie na serwer

Przycisk „Zapisz” tworzy jedno żądanie z pakietem:

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

Serwer stosuje operacje w kolejności: DELETE > INSERT > UPDATE, jako mini-transakcję.

Zalety podejścia:

• Minimalna liczba żądań – jeden batch na serię edycji.
• Reaktywny UI: praca z lokalną kopią danych.
• Prostota serwera: jeden endpoint bez wielu tras.
• Rozszerzalność: nowa encja dodana do pakietu bez zmian protokołu.

Co jest ważne

• Atomowe Punkty zapewniają integralność referencyjną bez duplikowania danych geograficznych.
• Model drzewiasty przez Foldery budowany reaktywnie na froncie.
• Dirty tracking + pakietowa synchronizacja redukują obciążenie sieci.
• Stos (PHP/Vue 3/Pinia/MariaDB) równoważy prostotę i wydajność.
• Otwarty projekt na GitHub z demo pod test/test.

— Editorial Team