[PostNAS Suite] NAS Import nach SQL Server

[Gunter Becker]

Hallo,

> Die Ablösung des SQL-Server durch PostgreSQL würde das gleiche erreichen   ;-)

Stimmt schon, aber dann wäre der Aufwand, unsere bestehende Anwendung umzustellen, vermutlich noch größer. Wenn alle Strick reißen, dann werde ich mir das mit PostgreSQL allein für die ALKIS-Daten noch einmal überlegen. Dann wäre ich wahrscheinlich besser dran als jetzt!

> Ich möchte nur auf eine Reihe möglicher weiterer Probleme hinweisen.

Weiter Probleme sind mir schon bewusst. Schließlich haben wir den Aufwand schon einmal für SQLite betrieben. Und da fehlen wesentlich mehr DB-Features als im SQL Server. Von daher ist dieser Weg vermeintlich schwieriger gewesen, als der Versuch, die Daten nach SQL Server zu bringen.

> Ihre SQLite-Lösung setzt (soweit ich das beurteilen kann) noch auf der alten PostNAS-Struktur auf, die die Relationen zwischen den ALKIS-Objekten über die Tabelle "alkis_beziehungen" geregelt hat. Diese Tabelle wird noch immer gefüllt (eigentlich längst hyperliquid), die meisten Anwendungen verwenden inzwischen aber die Verweise in den Objekt-Tabellen (hat, istGebucht, zeigtAuf , beziehtSichAuf, verweistAuf, bestehtAus, istBestandteilVon, dientZurDarstellungVon, ...). Die JOIN-Anteile in den SQL-Befehlen haben sich dadurch halbiert.

Das ist ja gerade ein Grund, warum wir an dieser Stelle von SQLite weg möchten, obwohl die Performance in der Anwendung gut ist. Allerdings haben wir hier mit den vielen JOINS, zumindest in den SQLite-Editoren, erheblich Probleme gehabt. Die Anzeige dieser Views dauert teilweise mehrere Minuten, was z.B. im Falle einer Fehlersuch, eine vernünftige Analyse unmöglich macht.

> Mehrfach-Beziehungen (1:N) werden als Arrays abgelegt, im JOIN wird die Function "any()" verwendet um auf ein Array-Element zu JOINen.
SQLite kann das nicht, kann der SQL-Server das?

Ja, gute Frage! Da ogr2ogr hier schon einige Warnungen beim Import ausgegeben hat, die ich dann mit der Option -splitlistfields umschiffen konnte (ich nehme einmal an, dass es sich hierbei um die Arrays handelt), würde ich davon ausgehen, dass das der SQL Server nicht kann. Wie man das Lösen kann, bzw. ob beim Import dadurch Daten verlorengehen, werde ich testen müssen. Vielleicht ist das ja dann auch das Ausschlusskriterium für den SQL Server!


> Ein Teil der Fortführungslogik findet nicht im PostNAS-Konverter (ogr2ogr) statt sondern ist durch Trigger in PostgreSQL gelöst.
Der NAS-Befehl INSERT wird von PostNAS direkt in die Objekt-Tabellen geschrieben. Bei NBA-Verfahren kommen aber auch DELETE und REPLACE vor.
PostNAS schreibt die notwendigen Informationen in die "delete"-Tabelle wo sich dann PostgreSQL-Trigger um das Löschen bzw. Terminieren der Vorgänger-Objekte kümmern. Es hat damals eine Weile gebraucht, bis diese Trigger in allen Konstellationen sauber gearbeitet haben.
Ist das auch mit SQL-Server lösbar?

Trigger und Prozeduren sollten kein Problem darstellen. Durch das Fehlen dieser Features für SQLite, war die Fortführung dort sehr aufwendig zu implementieren.

Viele Grüße, Gunter



Von: NAS [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Gunter Becker
Gesendet: Mittwoch, 7. September 2016 10:22
An: nas at lists.osgeo.org<mailto:nas at lists.osgeo.org>
Betreff: [PostNAS Suite] NAS Import nach SQL Server

Hallo zusammen,

als Dienstleister für Kommunen setzen wir aktuell den NAS-Konverter (via GDAL) zum Import der ALKIS Daten in unsere GIS-Anwendungen ein. Wir verwenden für unsere WebGIS-Anwendung als Datenbank-System ausschließlich den SQL Server, weswegen wir anfangs versucht haben die ALKIS-Daten via PostNAS in eben diesen zu importieren. Dies scheiterte in früheren GDAL Versionen gewöhnlich daran, dass Umlaute in den Zeichenketten durch "kryptische Zeichen" ersetzt wurden und die Zeichenketten dadurch länger wurden als per Definition erlaubt. Dies hatte dann schlussendlich ein Abschneiden der Zeichenketten beim Import zur Folge.

Da wir unseren Kunden kein zweites Datenbanksystem "zumuten" wollten, kam PostgreSQL bzw. PostGIS als DB nicht in Frage, weswegen wir auf SQLite ausgewichen sind. Hier erfolgte der Import einwandfrei. Auch die Performance von SQLite in unsere GIS-Anwendung lässt keine Wünsche übrig. Der große Nachteil von SQLite ist allerdings, dass das Weiterverarbeiten bzw. Aufbereiten der Daten durch fehlende Features wie Funktionen und Prozeduren sehr umständlich und extrem zeitaufwendig wird, was mit einem "kompletten" DB-System nicht der Fall sein würde.

Daher haben wir dem Import nach SQL Server ab der GDAL Version 2 erneut eine Chance gegeben. Allerdings erfolglos! Der oben beschriebene Importfehler ließ sich auf einen bekannten Bug in der GDAL Bibliothek zurückführen, der aber seit Version 2 gefixt ist.  Daher sind die Umlaute jetzt zwar richtig, dafür wird aber diesmal am Anfang einer jeden Zeichenkette ein "kryptisches" Zeichen angezeigt und am Ende der Zeichenkette fehlen dann jeweils 2 Zeichen. Dabei ist es unerheblich, ob es sich um eine Zeichenkette mit fester oder variabler Länge handelt.

Lange Rede (sorry) kurzer Sinn (kurze Frage): Hat vielleicht schon einmal jemand anders den Import nach SQL Server probiert und war erfolgreich. Oder hat vielleicht jemand noch eine Idee, wie man das Problem in den Griff bekommen kann? Evtl. eine andere Zeichenkodierung bei den NAS-Dateien verwenden oder etwaige zu setzende Optionen des ogr2ogr-Befehls, die für den Import noch eine Rolle spielen?

Ich bin für jeden Hinweis dankbar!

Danke schon einmal,

Gunter Becker
CSO GmbH


-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.osgeo.org/pipermail/nas/attachments/20160907/062d1bbe/attachment-0001.html>