LO Base: PostgreSQL Schemas

de-users
#1

Hallo,

ich verwende LO Base als Frontend für eine PostgreSQL Datenbank. Dabei liegen die Tabellen in verschiedenen Schemas.

Das Setting:

#2

Hallo Ulrich,

zu deiner eigentlichen technischen Frage kann ich nichts sagen. Aber mir fallen alternative Möglichkeiten ein, die zwar aufgrund der zwangsläufig vagen Information über dein System nur Denkanstöße und keine Lösungsvorschläge sein können, die ich dir aber trotzdem mitteilen möchte.

Normalerweise würde man bei einem jährlich sich wiederholenden Datenanfall das Jahr in den Schlüssel der betroffenen Tabellen aufnehmen, anstatt getrennte Datenbanken zu erstellen. Das nachträglich umzustellen wäre auch, was die Daten betrifft kein großes Problem, die INSERT-Statements sind schnell erstellt. Schwieriger wäre der Umbau in der Anwendung, da wäre ja das Jahr zusätzlich in irgendeiner Weise zu berücksichtigen.
Aber da ja, wie ich jetzt einmal annehme, vornehmlich in einem Jahr gearbeitet wird, könnte man dieses Problem ganz aus der Anwendung herausnehmen, indem man statt auf die Tabellen auf Views (auf Datenbankseite) oder Anfragen (auf LibO-Seite) zugreift, die jeweils die Bedingung für das Jahr enthalten. Views genügen, wenn man eigentlich nicht mehr auf alte Jahre zugreifen muss (man müsste da temporär die View ändern, um auf das Vorjahr zugreifen zu können), Abfragen sind da flexibler, weil man dann mehrere Kopien des Base-Dokuments (.odb) haben könnte, in denen der Satz der Abfragen jeweils ein anderes Jahr enthält. Ich habe den Verdacht, dass Abfragen minimal mehr Aufwand bedeuten als Views, aber das dürfte hier kaum relevant sein. Mit diesen aufs Jahr bezogenen Base-Dokumenten kann man bequem in verschiedenen Jahren arbeiten oder wohl eher auswerten. Selbst notwendige Code-Änderungen, die für vergangene Jahre nicht relevant sind, sind dann bequem machbar, weil der alte Code schon im Jahresdokument gesichert ist. Auch Datenbankänderungen, solange sie nicht zu gravierend sind, dürften sich durch die ABfragen abfangen lassen.

Ob das in deinem Fall etwas hilft, kannst nur du beurteilen.

Gruß

Gerhard

#3

Hallo Ulrich,

so wie ich es sehe dürfte der Vorschlag von Gerhard Views oder jahresweise Dokumente in Base hier am schnellsten zum Ziel führen. Damit würdest du sogar weitgehend datenbankunabhängig sein, solltest du mal auf die Idee kommen auf eine andere Datenbank zu migrieren.

Die andere Alternative wäre, wie auch von Gerhard angemerkt, das Jahr als Filterfeld mit in die Tabellen zu nehmen. Du könntest dann die Tabellen auch h jahresweise partitionieren. Allerdings musst du dann bei Abfragen das Jahr jeweils als Bedingung mitgeben. Das ist eigentlich der gebräuchliche Weg, wie er in vielen Anwendungen genutzt wird, z.B. in Buchhaltungssystemen. Da wählt man dann das Buchungsjahr, wobei das aktuelle beim Start vorausgewählt ist

Gruß
Ulrich

Hallo Ulrich,

zu deiner eigentlichen technischen Frage kann ich nichts sagen. Aber
mir
fallen alternative Möglichkeiten ein, die zwar aufgrund der
zwangsläufig
vagen Information über dein System nur Denkanstöße und keine
Lösungsvorschläge sein können, die ich dir aber trotzdem mitteilen
möchte.

Normalerweise würde man bei einem jährlich sich wiederholenden
Datenanfall das Jahr in den Schlüssel der betroffenen Tabellen
aufnehmen, anstatt getrennte Datenbanken zu erstellen. Das nachträglich

umzustellen wäre auch, was die Daten betrifft kein großes Problem, die
INSERT-Statements sind schnell erstellt. Schwieriger wäre der Umbau in
der Anwendung, da wäre ja das Jahr zusätzlich in irgendeiner Weise zu
berücksichtigen.
Aber da ja, wie ich jetzt einmal annehme, vornehmlich in einem Jahr
gearbeitet wird, könnte man dieses Problem ganz aus der Anwendung
herausnehmen, indem man statt auf die Tabellen auf Views (auf
Datenbankseite) oder Anfragen (auf LibO-Seite) zugreift, die jeweils
die
Bedingung für das Jahr enthalten. Views genügen, wenn man eigentlich
nicht mehr auf alte Jahre zugreifen muss (man müsste da temporär die
View ändern, um auf das Vorjahr zugreifen zu können), Abfragen sind da
flexibler, weil man dann mehrere Kopien des Base-Dokuments (.odb) haben

könnte, in denen der Satz der Abfragen jeweils ein anderes Jahr
enthält.
Ich habe den Verdacht, dass Abfragen minimal mehr Aufwand bedeuten als
Views, aber das dürfte hier kaum relevant sein. Mit diesen aufs Jahr
bezogenen Base-Dokumenten kann man bequem in verschiedenen Jahren
arbeiten oder wohl eher auswerten. Selbst notwendige Code-Änderungen,
die für vergangene Jahre nicht relevant sind, sind dann bequem machbar,

weil der alte Code schon im Jahresdokument gesichert ist. Auch
Datenbankänderungen, solange sie nicht zu gravierend sind, dürften sich

durch die ABfragen abfangen lassen.

Ob das in deinem Fall etwas hilft, kannst nur du beurteilen.

Gruß

Gerhard

Hallo,

ich verwende LO Base als Frontend für eine PostgreSQL Datenbank.

Dabei

liegen die Tabellen in verschiedenen Schemas.

Das Setting:
------------

Ich arbeite in den Formularen viel mit Unterformularen und mit
Listenfeldern. Dort muss ich entsprechend qualifizierte Tabellennamen

für die Datenquellen usw. angeben, also etwa

schema.tabelle

Soweit, so gut. Aber die Datenbank dient als Personendatenbank für
Tagungen, die jährlich stattfinden. Entsprechend heißt es z.B.

tagung_2019.tbl_person

oder

tagung_2020.tbl_person

Bestimmte Daten vererben sich von Jahr zu Jahr, die liegen im Schema
public, d.h. es heißt für solche Fälle etwa

public.tbl_laender

Das Problem:
------------

Beim Aufsetzen der DB für das jeweils nächste Jahr müssen nun in

allen

Formularen und allen Listenfeldern die Schemen-Angaben ersetzt

werden.

Das ist extrem nervig und vor allem fehleranfällig.

Ein Lösungsansatz:
------------------

In PostgreSQL gibt es für eine Connection den Befehl

set search_path to tagung_2019, public;

Dann werden unqualifizierte Tabellen-Referenzen, also etwa tbl_person

erst in tagung_2022, dann in public gesucht.

Meine Frage:
------------

Nun endlich die Frage: Kann man beim Aufrufen der LO-DB dafür sorgen,

dass irgendwie der search_path gesetzt wird? Dann könnte ich

sämtliche

Tabellen-Namen unqualifiziert lassen und müsste für das nächste Jahr
nur an dieser einen Stelle den Search-Pfad ändern...

Hat jemand eine Idee?

Ich arbeite mit LO 5.1.6.2 unter Linux mit dem DB Konnektor
(PostgreSQL Driver) aus dem Paket libreoffice-sdbc-postgresql. Bei

den

Datenbankeigenschafte gebe ich bei den erweiterten Einstellungen eine

Zeile der Art

host=myserver.xxx port=## dbname=mydb user=myuser

an. Wäre vielleicht an dieser Stelle eine Angabe des Search-Pfad

möglich?

Beste Grüße
Ulrich

--
Liste abmelden mit E-Mail an: users+unsubscribe@de.libreoffice.org
Probleme?
https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/
Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de
Listenarchiv: https://listarchives.libreoffice.org/de/users/
Datenschutzerklärung: https://www.documentfoundation.org/privacy

Ulrich Moser
Geschäftsführer - Trainer & Coach
ZPK Moser UG (haftungsbeschränkt)
Zentrum für Persönlichkeitsentwicklung und Kompetenztraining
Schlossstraße 7 - 78244 Gottmadingen
Tel. +49 (0)7734 395494
Mobil +49 (0)179 9155418
info@zpk-moser.de
www.zpk-moser.de

#4

Hallo,

danke erstmal für die wertvollen Tips!

Inzwischen bin ich auch noch auf einen Lösungsansatz gestoßen. Man kann tatsächlich in dem Connection-String folgendes ergänzen:

options=-csearch_path=tagung_2022,public

Beachte: keine Leerzeichen und Anführungszeichen.

Der beispielhaft angegebene search_path sorgt dafür, dass Tabellen erst in dem Schema tagung_2022 und dann in Schema public gesucht werden.

Die Sache hat aber einen Haken: Das funktioniert für Listenfelder u.ä., wo der Listeninhalt direkt über eine SQL-Abfrage erzeugt wird. Dort kann also sowas stehen wie

select ... from tbl_person

Aber es funktioniert nicht für die Tabellen, die Datengrundlage für Formulare und Unterformulare sind. Dort muss nach wie vor die Tabelle aus einer Liste von Tabellen ausgewählt werden - und diese Liste enthält nur qualifizierte Namen, das heißt incl. Schema. Löscht man hier per Hand das Schema vor dem Tabellenname, so findet LO die Tabelle nicht mehr.

Ob das alles auch über Views oder Abfragen funktioniert, habe ich noch nicht ausprobiert. Ich bin aber misstrauisch, denn mit dem Formular möchte ich ja Daten auch ändern und hinzufügen. Das geht aber in der Regel nicht über Views oder Abfragen. Oder etwa doch?

Beste Grüße
Ulrich

#5

Nachtrag: Siehe auch
https://www.postgresql.org/docs/9.6/libpq-connect.html

#6

Hallo Ulrich,

Die Sache hat aber einen Haken: Das funktioniert für Listenfelder u.ä.,
wo der Listeninhalt direkt über eine SQL-Abfrage erzeugt wird. Dort kann
also sowas stehen wie

select ... from tbl_person

Aber es funktioniert nicht für die Tabellen, die Datengrundlage für
Formulare und Unterformulare sind.

Du musst die Datengrundlage dann wohl auf Abfragen ändern. Abfragen
schlucken auch, wenn Du die GUI ausschaltest, das Entfernen der
Schemabezeichnung.

Eine Tabelle public.Name wird dann eben zu einem
SELECT * FROM Name
... und die Eingabemöglichkeiten bestehen weiter.

Ich habe übrigens gerade versucht, unter LO solche Schemata zu erstellen
- keine Berechtigung. Deshalb habe ich das Ganze auch nicht mit mehreren
Schemata überprüfen können.

Solange Du mit der Datenbank bei PostgreSQL bleibst ist das sicher kein
Problem. MariaDB/MySQL (und andere mir bekannten Datenbanken) kennen
diese Funktionalität gar nicht. Da wird, wie bereits hier berichtet,
eben das Jahr mit in die Tabelle genommen. Dann kann ich auch noch nach
entsprechender Vorfilterung die Datensätze des Vorjahres ansehen - oder
gleichzeitig Summen über alle Jahre bilden, wie ich das hin und wieder
bei einer Buchungsdatenbank mache.

Gruß

Robert