[PostNAS] PotNAS 0.8 - Datenbank-Schema

[Stefan Rahn]

Hallo,

also ich bin zwar im Moment in der glücklichen Lage, dass in unseren 
NAS-Daten offenbar keine langen gml_ids enthalten sind aber ich wäre 
trotzdem auch dafür dass sie vom Konverter immer auf 16 Stellen gekürzt 
werden.

Ich hab die beiden Abfragen eben mal auf unserer 9.1.12 DB getestet. Die 
mit substring dauert auch so lange. Das hat aber nichts mit der Postgres 
Version zu tun, sondern die Abfrage dauert deswegen so lange, weil bei 
Verwendung von substring kein Index verwendet werden kann. Wenn man mit

CREATE UNIQUE INDEX ax_buchungsstelle_gml3
   ON alkis.ax_buchungsstelle
   USING btree
   (substring(gml_id,1,16));

einen entsprechenden Index anlegt, ist die Abfrage genauso schnell!

Gruß,
Stefan Rahn

  
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 17:14, schrieb 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
>
>
> _______________________________________________
> NAS mailing list
> NAS at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/nas

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