<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hallo,<br>
<br>
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.<br>
<br>
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<br>
<br>
CREATE UNIQUE INDEX ax_buchungsstelle_gml3<br>
ON alkis.ax_buchungsstelle<br>
USING btree<br>
(substring(gml_id,1,16));<br>
<br>
einen entsprechenden Index anlegt, ist die Abfrage genauso
schnell!<br>
<br>
Gruß,<br>
Stefan Rahn<br>
<pre class="moz-signature" cols="72">
GDI-Service
Joachim-Jungius-Str. 9
18059 Rostock
Tel: 0381 40344445
E-Mail: <a class="moz-txt-link-abbreviated" href="mailto:stefan.rahn@gdi-service.de">stefan.rahn@gdi-service.de</a>
<a class="moz-txt-link-abbreviated" href="http://www.gdi-service.de">www.gdi-service.de</a>
</pre>
Am 11.09.2014 17:14, schrieb Jäger, Frank (KRZ):<br>
</div>
<blockquote
cite="mid:F2176AE4E9FFAF45BEA8D84DD6F4AF1A0C4E6329@skrzmxmbx01"
type="cite">
<pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:nas-bounces@lists.osgeo.org">nas-bounces@lists.osgeo.org</a> [<a class="moz-txt-link-freetext" href="mailto:nas-bounces@lists.osgeo.org">mailto:nas-bounces@lists.osgeo.org</a>] 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: <a class="moz-txt-link-abbreviated" href="mailto:stefan.rahn@gdi-service.de">stefan.rahn@gdi-service.de</a>
<a class="moz-txt-link-abbreviated" href="http://www.gdi-service.de">www.gdi-service.de</a>
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</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
NAS mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NAS@lists.osgeo.org">NAS@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/nas">http://lists.osgeo.org/mailman/listinfo/nas</a></pre>
</blockquote>
<br>
</body>
</html>