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 Am 14. November 2019 23:22:23 MEZ schrieb Gerhard Weydt <[email protected]>: >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 > >Am 14.11.2019 um 22:52 schrieb Ulrich Goebel: >> 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: [email protected] >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 [email protected] www.zpk-moser.de -- Liste abmelden mit E-Mail an: [email protected] 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
