Views
View erzeugen
Um eine View erzeugen zu können müssen Sie zuerst eine Tabelle markieren. Sie erhalten den Grund SQL der zugrundeliegenden Tabelle und können hierin Ihren SQL erweitern. Zur behilflichen Information steht Ihnen auf der rechten Seite die Datenstruktur der gesamten Datenbank zur Verfügung. Aus diesem Fenster heraus kann das erzeugte SQL auch sofort getestet werden ohne das Fenster zu verlassen.
Über "Attribute Table" wird festgelegt welches Generic Formular geöffnet werden soll wenn in MapEdit Professional Ebene Baum der View ausgewählt und Formular öffnen gewählt wird.
Über "Geometry Table" wird festgelegt wo die Geometrie gespeichert werden soll wenn in MapEdit Professional Ebene Baum der View zum Digitalisieren verwendet wird.
Wenn Sie den View in einem Generischen Formular verwenden wollen müssen die darauf achten das der View eine pro View Datensatz eindeutige FID oder ID Spalte benötigt, da ansonsten ggf falsche Werte angezeigt werden.
Bilden Sie eine eindeutige FID aus allen beteiligten Tabellen.
Beispiele
select (t.id||'-'||c.id) as FID, name from LAND a, BLUB b where ……
select (A.FID*100000 + B.FID) as FID, name from LAND a, BLUB b where ……
Verwenden sie nicht die Spalte "rownum". Die rownum ändert sich wenn Datensätze dazu kommen oder wegfallen und verursacht dann das falsche Datensätze bei Highlight etc angezeigt werden.
Warum braucht es eine eindeutige Spalte?
MapEdit liest, wenn man ein Formular öffnet/filtert, zuerst immer nur die Werte des Schlüsselfeldes (Primary Key), normalerweise FID oder ID. Wenn es kein Primary Key gibt, nimmt es, wenn vorhanden, das Feld FID oder ID. Nehmen wir an, eine Tabelle hat 1 Million Datensätze. Würde man alle Datensätze mit allen Spaltenwerten holen, würde das sehr lange dauern. Deshalb holt MapEdit zuerst nur die Werte des Schlüsselfeldes, also eine geringe Anzahl an Daten. Danach holt es damit nur die ersten 100 Datensätze. Wenn man dann zu Datensatz Nummer 101 blättert, holt es die nächsten 100 Datensätze. Dies ist aus Performance-Gründen so.
View registrieren
Hiermit kann ein View der noch nicht im Datenstrukturbaum vorhanden ist im System registriert werden. Das kann vorkommen wenn ein View händisch via SQL angelegt wurde.
Vermeiden Sie bitte das händische anlegen von Views via SQL und benutzen Sie immer die View erzeugen Funktion des AppBuilders!
Zum registrieren wählen Sie zuerst im Baum das Thema (einen der gelben Ordner) in dem der View Registriert werden soll. Wählen Sie dann im Register "Datenstruktur" den Knopf "View registrieren"
Wenn Sie kein Thema wählen ist der Knopf nicht sichtbar.
Falls View oder Tabelle nicht in der Liste erscheinen, siehe Bild.
Views können auch via SQL Befehl im SQL Query Tool registriert werden.
siehe dazu:
https://help.mapedit.de/admin-guide/mapedit-appbuilder/database-connections/Sql/QueryTool#views-registrieren
Achtung mit Views die andere Views benutzen
Wir raten dringend davon ab Views zu erzeugen die andere Views beinhalten. Wir unterstützen dies absichtlich auch nicht in der Benutzeroberfläche des AppBuilders.
Wir raten dazu in Views immer nur reine Tabellen zu verwenden. Nehmen Sie also einfach die View Definition die Sie einbinden wollen und integrieren Sie diesen direkt in ihren neuen View.
Einige Datenbanken u.a. Postgres erfordern das wenn eine Tabelle geändert wird das dann alle Views die diese Tabelle nutzen gelöscht und neu angelegt werden. In diesem Fall müssen dann auch die Views auf die Views gelöscht und neu angelegt werden. Das gleiche passiert wenn sie einen View aenderen wollen der von einem View genutzt wird. Das verwalten all dieser Abhängigkeiten schafft Probleme.
Bedenken Sie auch das wenn Sie jemals die Datenbankvorlagen verwenden wollen das dann ggf die gleiche Vorlage für einen anderen Datenbanktyp verwendet werden soll und Sie spätestens dann in Probleme laufen.
Tabelle/View Umleitung
siehe Eintrag unter Tabelle.
Postgres und Views
Postgres hat gegenüber allen anderen Datenbanken eine Besonderheit bei Views.
Wenn man bei Postgres einen View anlegt, dann ändert einem Postgres die View Definition die man eingetippt hat um und speichert den geänderten View ab. Der orginal View den man eingegeben hat wird nirgends in postgres gespeichert. Das ist verwirrend aber das ist so.
Hier ein kleines Beispiel:
Der Anwender tippe das hier ein:
... WHERE b.id = a.id_type AND a.category_electricity = 1
In der Datenbank erzeugt postgres den View so und speichert den View in der postgres system Tabelle pg_views so ab:
... WHERE ((b.id = a.id_type) AND (a.category_electricity = (1)::numeric))
D.h. postgres fügt Klammern ein, teilweise ändert es Funktionsnamen ab und stellt sogar das ganze select um. Und es fügt typen castings ein wie ::numeric, ::text etc.
In diesem Beispiel ist es noch nicht weiter schlimm aber in vielen Fällen kommt dann ein recht unlesbarer View heraus, der nichts mehr mit dem orginal zu tun hat, den der Anwender eingegeben hat. Was bei langen Views zur Verwirrung führt.
Um die Verwirrung zu minimieren, wird im AppBuilder das so gehandhabt, dass der Orginal SQL den der Anwender eingetippt hat und der View den postgres erzeugt hat, in der Hilfstabelle ME_VIEW abgespeichert wird.
In Feld VIEW_SQL_ORIGINAL steht der vom Anwender eingetippte View. In Feld VIEW_SQL_STORED steht der View den postgres erzeugt hat.
ME_VIEW ist eine vom Programm erzeugte Tabelle, keine postgres System Tabelle!
Damit wird dem Anwender der den View verändern will, wieder der orginal eingetippte View angezeigt und nicht der verwirrende interne postgres View.
Dieser wird aber nur angezeigt wenn der View sql der in pg_views steht auch gleich ist wie im Feld VIEW_SQL_STORED. Wenn diese nicht gleich sind, wird nicht der View aus ME_VIEW angezeigt sondern der wirkliche View aus pg_views. Dies kann vorkommen wenn der View nicht mit dem AppBuilder sondern mit einem anderen Tool wie pgadmin, dbeaver etc. geändert wurde. Deswegen sollte zum Ändern von views immer der AppBuilder benutzt werden.
Desweiteren sollte man wissen, dass die wirklich wahre View Definition der Datenbank nur in postgres system tabelle "pg_views" steht.
Was in ME_VIEW steht kann falsch sein wenn ein Anwender mit einem Fremdtool in der Datenbank Veränderungen vornimmt, oder händisch Views via sql ändert oder erzeugt. In ME_VIEW müssen auch nicht alle Views stehen.
Also wenn man die wirklichen Vies braucht nie auf ME_VIEW gehen!! sondern immer auf
select * from pg_views where schemaname=current_schema order by viewname;
oder
select * from ME_ALL_VIEWS was ein View auf pg_views ist. ME_ALL_VIEW ist ein View der bei allen Datenbanktypen auf die jeweils dahinter stehende Systemtabelle geht.
Im AppBuilder wird in der Strukturanzeige immer der Orginal View angezeigt wie er in der Datenbank steht.
Wenn man einen View den man mit dem AppBuilder über die UI angelegt und bearbeitet hat, dann sieht man den orginalen View den man eingetippt hat, sofern er nicht vom Anwender mit einem anderen Tool oder via sql verändert wurde.
Postgres Version 14 erzeugt ein anderes Ergebnis als in Version 12. D.h. wenn man den gleichen View mit postgres Version 12 und 14 anlegt dann wird ein anderer View in pg_view gespeichert.
D.h. dann passt das was in ME_VIEW im Feld VIEW_SQL_STORED nicht mit dem view aus PG_VIEW zusammen. Und es kommt der View so wie er in postgres gespeichert ist.
Es macht dort zum Beispiel unter anderem sowas:
TRIM(BOTH FROM (in Version 12)
wird zu:
btrim(translate (in Version 14)