[PostNAS] Problem beim Update

[Jürgen E. Fischer]

Moin Frank,

On Thu, 30. Jan 2014 at 12:41:31 +0000, Jäger, Frank (KRZ) wrote:
> Abgabeart:
> 1000 stichtagsbezogen (ohne Historie)
> 1100 stichtagsbezogen (mit Historie)
> 3000 fallbezogen (ohne Historie)
> 3100 fallbezogen (mit Historie)
 
> "stichtagsbezogen":  Bei einer neuen Lieferung wird der Stand zum Zeitpunkt
> der Abgabe geliefert.
 
> "fallbezogen": Es werden auch alle *Zwischenstände* geliefert, auch solche,
> die bei Abgabe schon nicht mehr aktuell sind.
 
> "ohne Historie": Ein untergegangenes Objekt bekommt ein DELETE
> 
> "mit Historie": Ein Untergegangenes Objekt bekommt die Änderung "ended=timestamp"

> Bei genauerer Betrachtung machen nur die Abgabearten 1000 und 3100 einen
> Sinn: 1000 -> kill, 3100 -> hist

3100 geht derzeit nicht, da der NAS Treiber update noch nicht unterstützt.
Historie wird darüber aufgebaut, dass der Trigger bei delete und replace das
endet des gelöschten bzw. ersetzten Objekt setzt.

Dabei stellen aber die gekürzten gml_ids im Schema ein Problem dar - das dürfte
aber auch den Fall ohne Historie betreffen, denn bei der Fortführung werden die
gml_ids noch mit Timestamps versehen.  Im Schema sind aber die gml_ids dafür zu
kurz und werden einfach abgeschnitten und sind damit i.d.R. nicht mehr
eindeutig.

Da allerdings nur jeweils ein Objekt gelöscht oder ersetzt werden soll und in
der Datenbank zu dem Zeitpunkt auch nur noch ein anderes Objekt mit diesem
(gekürzten) gml_id vorhanden sein sollte, kann der Trigger die gml_id auch ggf.
kürzen, um das betroffene Objekt zu finden.

Allerdings scheint es bei den Datenlieferanten auch keine Einigkeit darüber zu
geben, ob der Timestamp nun in gml_id oder identifier gehört.  Der Timestamp
kam hier, wenn ich mich recht entsinne, auch schon in einem der beiden, beiden
oder gar keinem vor.  Das längere identifier-Feld hatte ich ergänzt, damit man
an einer Stelle den kompletten gml_id behält und nicht nur "raten" muß.  Das
war aber wohl bevor ein Fall mit Timestamp im gml_id statt identifier
aufgetaucht ist - in dem Fall hilft das dann natürlich auch nicht.

Zudem dehnt sich das Problem der gekürzten gml_ids auf alkis_beziehungen aus.
Dort ist damit auch nicht zu erkennen zwischen welchen Objektständen die
Beziehungen bestehen/bestanden.

Aber eigentlich ist dieses Problem künstlich. Die Beziehungen sind ja
eigentlich Eigenschaften der Objekte.  Wenn die so abgelegt würde, wie alle
anderen Eigenschaften, wären sie ein Feld in der jeweiligen Tabelle.  Der
NAS-Treiber müßte das sogar hergeben, wenn die entsprechenden Felder im Schema
vorhanden wären (ggf. für 1:n Relationen als varchar[]).

Damit wäre zwar das Fortführproblem aus der Welt, dürfte aber so ziemlich alle
vorhandenen Abfragen überarbeiten.  Damit ist das wohl auch unpraktikabel.


Jürgen

--
Jürgen E. Fischer         norBIT GmbH               Tel. +49-4931-918175-31
Dipl.-Inf. (FH)           Rheinstraße 13            Fax. +49-4931-918175-50
Software Engineer         D-26506 Norden               http://www.norbit.de
QGIS PSC member (RM)      Germany                      IRC: jef on FreeNode                         

-- 
norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH
Rheinstrasse 13, 26506 Norden
GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502