[PostNAS] PotNAS 0.8 - Datenbank-Schema

[Jäger, Frank (KRZ)]

Hallo,
ja die unterschiedlich langen IDs mal mit und mal ohne angehängten Zeitstempel wurden aus einer Version OHNE Historie eingelesen.
Also NBA: Abgabeart "1000 stichtagsbezogen (ohne Historie)", PostNAS: FUNCTION delete_feature_kill().

Ich bekomme eine andere Stadt als Abgabeart "3100 fallbezogen (mit Historie)", brauche aber für das Web-GIS nur aktuelle Objekte.
Der Versuch, diese NAS-Daten mit PostNAS 0.8-Schema und "delete_feature_kill" zu konvertieren ist gescheitert.
Diese Kombination geht derzeit gar nicht, da muss noch am Trigger gefeilt werden, der weiß ja noch nicht, dass es jetzt auch lange gml_id gibt.

Die langen gml_id bzw. der Mix kurz/lang bereiten mir auch bei der Auswertung ziemliche Probleme:
Ich bin bestrebt, die Views und Programm möglichst rubust zu machen. Sie sollten zukünftig möglichst mit gemischt langen IDs arbeiten können und auch mit Datenbanken mit und ohne historische Objekte. Also in jeder vorkommenden Kombination.

Die Relationen-Spalten enthalten aber leider immer nur Verweise auf die kurzen IDs.
Datenbanktechnisch ist das also eigentlich eine kaputte Relation weil das Feldformat auf beiden Seiten nicht zusammen passt. 
Lösung: Man muss das beim JOIN zurecht stutzen. Diese Views werden dann aber unerträglich langsam. Die Kombination von "Substring" und "Any" ist grausam, mein PostgreSQL 8.4 macht da schlapp.

Vielleicht kann das folgende mal jemand mit einer aktuelleren DB-Version testen:

-- Test mit Relation:   (herrschende) Buchungsstelle (hat Recht) "an" (dienende) Buchungsstelle:

-- Falsch und schnell, Findet nicht die Fälle mit langer ID:
SELECT dien.gml_id, herr.gml_id
FROM ax_buchungsstelle dien 
JOIN ax_buchungsstelle herr  ON dien.gml_id = ANY (herr.an)
WHERE dien.endet IS NULL AND herr.endet IS NULL
LIMIT 300;
-- 78 ms

-- findet alle Fälle, ist aber unbrauchbar langsam:
SELECT dien.gml_id, herr.gml_id
FROM ax_buchungsstelle dien 
JOIN ax_buchungsstelle herr  ON substring(dien.gml_id,1,16) = ANY (herr.an)
WHERE dien.endet IS NULL AND herr.endet IS NULL
LIMIT 300;
-- 19454 ms

Die Ausführung wird etwa 250mal langsamer wenn man Substring(gml_id) auf Any(Array) Joint!
Diese Relation steckt z.B. im View "doppelverbindung", der dann z.B. für den CSV-Export aus der Auskunft verwendet wird.
Da wartet man dann eine halbe Minute auf 2 Zeilen. Das geht so nicht! 

Wozu sind die langen gml_id eigentlich nützlich?
Das war viel einfacher, als die beim Import auf 16 Zeichen getrimmt wurden. Braucht man die Erweiterung für Datenbanken mit Historie?

@Jürgen: deine signierte Mail hat wieder der Spamfilter gefressen. Ich mache das Ticket noch mal auf .

MfG
Frank Jäger


Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im Auftrag von Stefan Rahn
Gesendet: Donnerstag, 11. September 2014 16:24
An: NAS Schnittstelle via ogr2ogr
Betreff: Re: [PostNAS] PotNAS 0.8 - Datenbank-Schema

Alles klar. Danke für die Info.

 
GDI-Service
Joachim-Jungius-Str. 9
18059 Rostock
Tel: 0381 40344445
E-Mail: stefan.rahn at gdi-service.de
www.gdi-service.de
 
Am 11.09.2014 16:21, schrieb Jürgen E. Fischer:
Moin Herr Rahn,

On Thu, 11. Sep 2014 at 15:46:51 +0200, Stefan Rahn wrote:
die von Ihnen erwähnte Erweiterung der gml_id um einen Zeitstempel nach
Einspielung von Fortführungsdaten habe ich bisher nicht feststellen können.

Bei mir hat das alte Objekt und das neue die gleiche gml_id...  Wir verwenden
ja die Variante mit Historie. Findet diese Erweiterung  evtl. nur statt, wenn
man keine Historie verwendet?

Die Timestamps werden nicht beim Import produziert, sondern lediglich aus den
Daten übernommen - die Neuerung ist, dass die Timestamps nicht mehr
abgeschnitten werden, falls sie vorhanden sind.

Es kommt wohl auf die Software an die die Updates produziert.  Manchmal gibt es
Timestamps im gml_id, manchmal im identifier und manchmal auch gar nicht und
man muss beginnt einbeziehen.

Mit freundlichen Grüßen,
  Jürgen Fischer
  norBIT GmbH
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 7599 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20140911/13922c26/attachment.bin>