Juchhei, mein Spezialgebiet
Hallo!
Wir haben sowas gerade umgesetzt bzw bauen es weiter aus (SEP3 unter PostgreSQL/PostGIS mit Webfrontend und als Clients QGIS, ArcGIS und Geoserver/UMN).
zu 1.)
Kommt auf dein Design an. Wenn du eine eigene Datenbank einsetzen willst würde ich die notwendigen Daten mit Hilfe eines FDW dort einbinden. Man hat dann keinen Aufwand mit der Aktualisierung usw.
zu 2.)
Ich verwalte alle Geometrien unabhängig von den eingegebenen Koordinaten mit UTM32N weil wir auch eine spezielle Transforation benutzen, die auch in der DB integriert ist. Gemanagt wird das von einem Insert/Update-Trigger, der bei Änderungen an den Koordinaten/Geometrie die jeweils andere Seite anpasst. So ganz allgemein sieht die Geometrieerzeugung etwa so aus:
select st_transform(st_setsrid(st_makepoint(xcoord, ycoord[, zcoordb]), <Eingabesystem>), 25832) from <Stammdatentabelle>
zu 3.)
Ich habe für die Aufschlußdaten die vorgegeben Schlüsselfelder prjid, locid,recid,… verwendet also einen mehrspaltigen Schlüssel erzeugt. Für die Weboberfläche und die Webservices gibt es noch eine zusätzliche Serial-Spalte mit Unique un NotNull, falls die nicht mit den PKs umgehen können. Das hat den Vorteil das ich in jeder Relation Zugriff auf alle übergeordneten Einträge habe ohne große Join-Orgien erzeugen zu müssen.
zu 4.)
Schau die mal FDW (Foreign Data Wrapper) an. Oder prüfe, ob du du deine eigenen Daten in einem eigenen Schema statt einer anderen Datenbank unterbringen kannst. Weitere Möglichkeiten wären da auch sicher Materialized Views, die einfacher zu händeln sind als Trigger wenn es nur ums Abbilden einer Urtabelle sind. Wie auch immer, hängt auch davon ab was du alles anstellen willst. Und Trigger gehen immer auf die Performance, allerdings macht sich dass hier für diese Anwendung eher nicht bemerkbar.
Soweit erstmal für den Anfang. Falls du noch Fragen hast, stell sie einfach
Grüße Uwe