[PostNAS] Problem beim Update

[Ralf Suhr]

Hallo Jürgen,

deine Lösung alle Einträge aus der Tabelle alkis_beziehungen auch in allen 
anderen Tabellen zusätzlich zu führen, halte ich für die beste Lösung. Damit 
wäre das Lebenszeitproblem für die Verknüpfungseinträge gelöst und das NBA für 
stichtagsbezogene Abgaben ist machbar.

Ein Trigger auf allen Tabellen ist dann nur noch notwendig, um überlange 
gml_id zu kürzen und den eventuell enthaltenen Zeitstempel als Lebenszeitende 
für den Vorgänger zu setzen.

Die Änderungen an den gdal Quellen habe ich als Ticket eingestellt #5372. 
Damit wäre man abwärtskompatibel und kann die Änderungen in den SQL Abfragen 
später vornehmen.


MfG
Ralf Suhr

Am Donnerstag 30 Januar 2014, 15:17:08 schrieb 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