[PostNAS] Antw: Re: Problem beim Update

[Jäger, Frank (KRZ)]

> -----Ursprüngliche Nachricht-----
> Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im
> Auftrag von Karsten Bleßmann
> Gesendet: Donnerstag, 30. Januar 2014 10:33
> Betreff: [PostNAS] Antw: Re: Problem beim Update

...

> es gibt wohl vier Arten, 

Ja!

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

1100: Was will man mit einer "Historie", wenn man nicht jeden einzelnen Schritt rekonstruieren kann sondern nur die Sprünge von einem Liefertermin zum nächsten?

3000: Alle einzelnen Schritte der Fortführung im Primärbestand werden im Sekundärbestand nachvollzogen. Am Ende hat man dann den gleichen Stand wie ohne die Zwischenschritte?


> Man kann die doch daran erkennen,
> dass die einen Eintrag bei "endet" haben ... oder? 

Ja, kann man.


> Bei *kill sind die dann komplett raus ... oder?

Ja, sind sie.


Bei der Entwicklung der Auskunft (PHP-Scripte) bin ich davon ausgegangen, dass mein Client keinen "Zeitschieber" hat, mit dem ich einen Zeitpunkt einstellen kann, den ich gerne beauskunftet hätte. Daher gehen die Programme vereinfacht von einer kill-Variante der Datenbank aus, die nur den aktuellen Stand enthält.

Man könnte die Programme wahrscheinlich mit einer Hist-Datenbank verwenden, wenn man konsequent alle eingebetteten und gespeicherten SQL-Views für *JEDE Tabelle* um den Filter "WHERE a.endet IS NULL AND b.endet IS NULL AND c.endet IS NULL AND ... " erweitern würde.
Das würde dann aber unnütz aufgebläht und noch komplizierter ohne einen Vorteil davon zu haben. Man hätte dann nur die "aktuelle" Auskunft aus einer Datenbank voller Historie.

Für eine Auskunft mit steuerbarem Zeitpunkt zu bekommen:
"WHERE AuskunftZeitpunkt > beginnt AND (AuskunftZeitpunkt < endet OR endet IS NULL)" für JEDE Tabelle.

Das beträfe dann übrigens auch die Views für die Kartendarstellung (Mapfiles).

Aus einer Hist-Datenbank(-Kopie) kann man eine Kill-Datenbank erzeugen, indem man in allen Tabellen die Sätze löscht, die einen Eintrag in Spalte "endet" haben. Siehe Datei "alkis-functions.sql":   FUNCTION alkis_delete_all_endet()

Anwendung:
$ psql -c "SELECT alkis_delete_all_endet();" -d alkis07datenbank

MfG
F.J.

..
> Beste Dank & beste Grüße
> KBL
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 7618 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20140130/f66034d3/attachment.bin>