Feature-Request: Zusammenfassen mehrerer Datensätze via Postgres-Vererbung

[ruhri]

Beim Einsammeln mehrerer Ämter/Bestandsdatenauszüge gibt es immer wieder Probleme, die Daten aller Ämter in einer DB im Public-Schema zusammenzubringen, ein defekter Datensatz zerschießt u.U. die DB/bzw. den Import. Da es ja seit kurzem möglich scheint - ich habe es mangels gepatchtem GDAL noch nicht getestet - Importe in ein anderes als das Public-Schema laufen zu lassen, wäre es dann nicht denkbar, für jede räumliche Zuständigkeit (Katasteramt) ein Schema in der DB anzulegen und mittels eines übergeordneten "Eltern-Schemas" und Vererbung den Zugriff für die Anwendung (QGIS/Mapserver) via Eltern-Schema global auf die Summe der Kind-Schemata zu ermöglichen?

Vorteile:

• jeder Datensatz eines Amtes bleibt autark
• mittels mehrerer paralleler Importinstanzen schnellere Importe (v.a. Postprocessing)
• schnellere Abfragen und Verwaltung der DB aufgrund kleinerer Tabellen
• größere Robustheit der Anwendung bei Importen/Updates, im schlimmsten Fall geht nur der Datensatz eines Amtsbezirks kaputt

[jef-n]

Die Änderung für's volle ALKIS-Schema sind bereits in GDAL trunk eingeflossen - man braucht also nur noch einen GDAL trunk build (z.B. gdal-dev aus osgeo4w). Für den Import in mehrere Schemata braucht man das allerdings nicht - das ging mit active_schema auch schon vorher.

Dort geht's im wesentlichen nur um die Möglichkeit mit einer zentralen GFS-Datei dafür zu sorgen, das die Attribute aus den NAS richtig auf die Felder im SQL-Modell gemappt werden. Dadurch wurden auch einige Workarounds überflüssig (zeigtAufExternes/objektkoordinaten etc).

Bei der Gelegenheit habe ich allerdings auch Unterstützung dafür eingebaut, dass verschiedenen Schemata verwendet werden können, was im norBIT/alkisimport@pre-fullschema Branch noch nicht vorgesehen war.

Zurück zu Deiner Idee: Die bestünde darin alkis-schema.sql nur in einem Elter-Schema laufen zu lassen und in den Kindschemata jeweils nur CREATE TABLE kind.tabelle INHERITS elter.tabelle für die einzelnen Tabellen auszuführen? Hört sich auf jeden Fall interessant an...

[ruhri]

Ja so habe ich das gemeint, alle Abfragen gehen auf die Eltern-Tabelle und bspw. pro Amtsbezirk gibt es eine Kind-Tabelle - diese könnte ja sogar automatisch generiert werden, aus dem Datensatz (gmlid) kennen wir ja das Amt. Hätte auch den Vorteil, dass die Kind-Tabellen in etwa in gleich große "Häppchen" partitioniert wären, was der Performance bei Abfrage zuträglich sein dürfte. Evt. hat das dann noch Vorteile ab PG 9.6, weil die DB Abfragen eigenständig auf mehrere Prozesse aufteilt? Gleichzeitig kann man den im Import-Prozess dann räumlich separiert parallel ausführen (mit xargs/Gnu-parallels Sub-Prozesse starten), das skaliert meiner Erfahrung nach sehr gut mit der Anzahl der CPU-Cores (abzgl. ein Core fürs System)... Der DB-Spezialist bist Du, aber ich vermute, dass die Auswirkungen bzw. notwendigen Umbauarbeiten bez. der Import-Prozesse und des Schemas auch nicht so gravierend wären?

[jef-n]

Ich bin gerade dabei Hamburg und NRW in eine Datenbank zu spielen - mit Vererbung. Da die Indizes nicht vererbt werden, war das nicht so einfach wie gedacht. Außerdem kommen sich die Ableitungsregeln immer noch in die Quere, weil die Basistabellen gelockt werden. Man müßte auch noch untersuchen, wie es sich verhält, wenn man die Daten einfach wie gehabt importiert (nur in unterschiedliche Schemata) und sie stattdessen über Views zusammenbringt.