[PostNAS] 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 Jürgen E. Fischer
> Gesendet: Donnerstag, 30. Januar 2014 15:17
> An: nas at lists.osgeo.org
> Betreff: Re: [PostNAS] Problem beim Update
> 
..
> 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


Moin Jürgen.
Ich habe nie verstanden, warum die Relationen als Tabelle "alkis_beziehungen" sozusagen ausgelagert wurde. Eigentlich ist es ja das Wesen einer relationalen Datenbank, dass die Relationen direkt zwei Tabellen verbinden. Dann stünden Standard-Werkzeuge wie Foreign-Key-Constraint und Delete-Cascade zur Verfügung.

Ich habe einfach mal darauf vertraut, dass die Entwickler sich schon irgendetwas dabei gedacht haben, dass es vielleicht nicht anders möglich ist bei der Komplexität von ALKIS oder der NAS-Struktur.
In der Phase der grundlegenden Entwicklung fand die Kommunikation zwischen der WhereGroup und Frank Warmerdam statt. Es ist zu der Zeit kaum etwas kommuniziert worden. Ich erinnere mich, dass Anwender sich damals (~ 2009) für andere Konverter entschieden haben, weil da monatelang keine Infos kamen. Das Projekt schien tot zu sein.
Auf der FOSSGIS in Osnabrück haben wir dann erfahren, dass die Lösung fast fertig war ...

Irgendwann stand dann die Version mit dieser "ungewöhnlichen" Abbildung der Relationen zur Verfügung und wir haben uns irgendwie damit arrangiert. Ich wusste nicht, dass der Konverter die Relationen auch "in üblicher Weise" abbilden kann! Das wäre eine große Erleichterung beim Entwickeln von Views und bei der Aktualisierung (gewesen). Diese Trigger-Functions sind doch nur eine Notlösung.

Aber Relationen über Arrays abzubilden wäre noch schlimmer als sie auszulagern [1] . Das Verknüpfungsfeld einer 1:N-Relatiuon wird doch üblicherweise auf der N-Seite abgelegt. Die "inversen Relationen" in ALKIS wären redundant und könnten entfallen. Nur für N:N brauchen wir eine Verbindungstabelle (oder Arrays).

Mit der Umstellung auf GeoInfoDok 7 wäre eine Gelegenheit, das mal zurecht zu rücken. Da muss dann sowieso vieles neu gestrickt werden.

Oder würde der Konverter auch eine "sanfte Migration" unterstützen, wo wir jeweils eine überschaubare Menge an Tabellen umstellen? Schema und Anwendung jeweils gleichzeitig.

Frank


[1]  http://www.postgresql.org/docs/8.4/static/arrays.html   Kapitel: 8.14.5. Searching in Arrays
"Tip: Arrays are not sets; searching for specific array elements can be a sign of database misdesign. Consider using a separate table with a row for each item that would be an array element. This will be easier to search, and is likely to scale better for a large number of elements."
-------------- 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/2c2bcd78/attachment-0001.bin>