[PostNAS] PostNAS 0.8 - Datenbank-Schema

[Jäger, Frank (KRZ)]

Hallo,
da ich die Mails von Jürgen E. Fischer derzeit nicht erhalte (M$ Exchange hat ein Problem mit PGP-Signaturen), kopiere ich die Mail, auf die ich mich beziehe, aus dem Web-Archiv unten dran.

Die Verlängerung der gml_id hat sehr viel Kopfzerbrechen bereitet. Die Idee von Stefan Rahn mit dem Index auf einem Substring war hilfreich und hat die Laufzeitprobleme beseitigt. Ich habe entsprechende Indices im Schema zugefügt.

Ursprünglich waren die "gml_id" in unserem Schema im PostNAS-SVN  http://trac.wheregroup.com/PostNAS/browser/trunk  bis zur Version 0.7 alle Fix 16. 
In der Norbit-Version https://github.com/norBIT/alkisimport waren die gml_id dann alle auf varchar geändert worden. Ich bin davon ausgegangen, dass diese Änderung für die sichere Fortführung mit dem Historie-Trigger (z.B. für die Update-Funktion) zwingend benötigt wird.

Die Inhalte der gml_id als Hauptindex jeder Tabelle waren dann manchmal mit und manchmal ohne Zeitstempel hinter der 16stelligen Basis-ID.
Die Verweise aus Relationen aus anderen Tabellen aber immer nur 16stellig.

Auf Dauer halte ich es für sinnvoll in den beiden divergierenden Entwicklungszweigen zumindest ein einheitliches Datenbankschema zu haben. Dann kann man eine Datenbank z.B. für Mapserver-WMS und für QGIS verwenden und braucht die Daten nicht in zwei verschiedene Formate konvertieren.

Also habe ich das Schema im PostNAS-SVN, alle Views, das Post-Prozessing und die Programme für Navigation und Buchauskunft daran angepasst. Bei jeder Verwendung einer gml_id in SQL oder im PHP muss man individuell überlegen, welche der beiden Seiten immer eine kurze und welche möglicherweise auch manchmal lange IDs enthält. Die manchmal-lange muss man dann im JOIN oder vor der Verwendung im Programm auf 16 Stellen kürzen.
Das hat einiges an Arbeit gekostet. Ich habe die Datenbanken von 14 Kunden inzwischen darauf umgestellt, also alle Städte komplett neu konvertiert. Ich suche nur noch einige Restfehler, dann ist es geschafft.

Und nun wird einfach alles wieder zurück gedreht!? Die Änderung hatte gar keinen bestimmten Zweck?
Das erinnert mich irgendwie an das Märchen von Hase und Igel.

Wir brauchen ein besseres Konzept!

Frank

-----

	Moin Frank,

	On Thu, 11. Sep 2014 at 15:14:28 +0000, Jäger, Frank (KRZ) wrote:
	> 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. 

	Das ist ein Argument.  Die langen Schlüssel haben aber nur unmittelbar bei der
	Fortführung Sinn.  Das Hauptziel ist wohl sicherzustellen, dass die Fortführung
	auch zur Datenbank paßt.  In die Datenbank sollten sie gar nicht kommen
	(GeoInfoDok, 5.1.1).

	Daher habe ich jetzt alle gml_id und Relation wieder auch character(16)
	gestellt ([1]).  Außer in "delete" gibt es jetzt nur noch 16stellige gml_ids.
	Darin sind auch einige Änderungen raus (r332[2] enthalten; verbleibende
	Unterschiede in der Commit-Nachricht zu [1]).


	Jürgen



> -----Ursprüngliche Nachricht-----
> Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im
> Auftrag von Jäger, Frank (KRZ)
> Gesendet: Donnerstag, 11. September 2014 17:14
> An: NAS Schnittstelle via ogr2ogr
> Betreff: Re: [PostNAS] PotNAS 0.8 - Datenbank-Schema
> 
> 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. 
-------------- 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/20140915/420a329e/attachment.bin>