Branch-Versionierung
ArcGIS Pipeline Referencing (APR) basierte bei der Einführung auf dem traditionellen Versionierungsmodell für Geodatabase-Transaktionen. Als eine der nächsten Generationen von ArcGIS-Anwendungen wurde APR jedoch mit ArcGIS Enterprise 10.6.1 und ArcGIS Pro 2.2 um die Kompatibilität mit Branch-Versionierung erweitert. In späteren Versionen erfordern neuere Funktionen wie dienstbasierte Bearbeitung, Integration des Utility Network und Konfliktvermeidung die Branch-Versionierung. APR mit Branch-Versionierung ist das empfohlene und bevorzugte Implementierungsmuster für Pipeline-Organisationen.
- Branch-Versionierung folgt einer dienstbasierten Architektur zum Anzeigen und Bearbeiten von Daten. Sie ermöglicht lange Datenbanktransaktionen über Feature-Services und nutzt den Version Management Service von ArcGIS Server.
- Direkter SQL-Zugriff auf die relationale Datenbank wird mit diesem Geodatabase-Transaktionsmodell nicht unterstützt oder empfohlen.
- Datenbankansichten sind eher für traditionelle Versionierung und Datenebenen-Joins oder Integrationen geeignet. Ohne mehrversionierte Ansichten sollten Updates/Einfügungen/Löschungen per SQL nicht auf Feature-Classes angewendet werden, die branch-versioniert sind, da dies zu Datenkorruption und unerwartetem Verhalten in ArcGIS-Anwendungen führen kann.
- Create Database View-Geoverarbeitungswerkzeug akzeptiert branch-versionierte GDB als Eingabearbeitsbereich, ist jedoch nicht branch-versionierungsbewusst.
Designüberlegungen
Benutzer sehen in dieser veränderten dienstbasierten Landschaft zahlreiche Vorteile. Grundlegende Aufgaben wie Berichtserstellung und Datenbankintegrationsschnittstellen sind jedoch entscheidend für Geschäftsprozesse. Lösungsarchitekten und GIS-Manager haben die Geschäftsanforderungen sorgfältig neu bewertet und arbeiten mit einer Mischung neuer Designmuster. Weitere Einblicke bietet Utility Network Journey: Branch Versioning and SQL von @RobertKrisher.
- REST API: Die unterstützte Methode zur Abfrage branch-versionierter Daten erfolgt über die REST API, z.B. Query (Feature Service/Layer), sofern passend und erforderlich. Spezielle Methoden wurden in REST und ArcGIS-Clients entwickelt, um die Datenintegrität beim Zugriff auf branch-versionierte Daten sicherzustellen.
- Python-Skripting: Die ArcGIS API for Python ist branch-versionierungsbewusst; Skripte können zur Berichtserstellung aus branch-versionierten Geodatabases verwendet werden. Diese Skripte können als geplante Jobs ausgeführt werden, oft außerhalb der Geschäftszeiten, um Datenberichte zu erstellen.
- Nicht versionierte Veröffentlichungs-Geodatabase: Erforderliche Datensätze können in eine nicht versionierte Veröffentlichungs-Geodatabase repliziert werden, die für Berichte, SQL-Ansichten, Integration usw. genutzt werden kann. Beachten Sie den Mehraufwand durch den Replikationsprozess und die Pflege einer sekundären Geodatabase-Kopie. Daher wird ein sorgfältiges Design empfohlen, basierend auf Layer-Anforderungen, Replikationshäufigkeit, Delta-Änderungen und einer Kosten-Nutzen-Analyse.
- SQL-Ansichten: Zusätzliche SQL-Logik kann für die Definition von Ansichten (nur Lesezugriff) auf branch-versionierte Daten verwendet werden. Das Dokument Branch Version SQL Views zeigt mehrere Beispiele:
- Erstellen von materialisierten Ansichten und Aktualisieren von Ansichten
- Erstellen von Berichtstabellen und Aktualisieren von Tabellen
Beachten Sie, dass die Option SQL-Ansichten als sekundär für Legacy-Datenbankoperationen gilt; INSERT-, UPDATE- und DELETE-Funktionen sind nicht verfügbar. Die Abfrage über REST API ist die empfohlene Best Practice für die dienstbasierte Architektur.
Abschließende Gedanken (mit freundlicher Genehmigung von xkcd)
