Hallo,
wir arbeiten im Büro mit einer OOo Base Datenbank welche unsere Stunden erfasst und nach Projekten, Mitarbeitern und Kategorien gliedert. Das funktioniert soweit ganz wunderbar.
Jetzt würde ich gerne für die Kunden eine monatliche Übersicht der Stunden gegliedert nach Projekten und Kategorien erstellen. Also jeder Kunde erhält ein pdf mit einer Liste der Projekte, in denen Stunden geleistet wurden, wobei für jeses Projekt die Stunden aufgeteilt nach den letzten 8 Monaten und der Kategorie angezeigt wird. Hierfür habe ich in der Datenbank die Abfrage q_mtl_Übersicht erstellt, die auch liefert was ich brauche. Nur dauert die Abfrage bei den bis kjetzt knapp 4000 Datensätzen knapp 10 Sekunden.
Ist das normal und ich muss damit leben?
Habe ich einen Fehler gemacht?
Gibt es einen besseren/eleganteren Weg?
Ich benutze Libre Office Version: 5.2.0.4 auf einem Win 10 64 Bit Rechner.
Vielen Dank für eure Hilfe,
Jan
Abfrage sehr langsam
Moderator: Moderatoren
Abfrage sehr langsam
- Dateianhänge
-
- Projektplanung - Kopie.odb
- (191.96 KiB) 178-mal heruntergeladen
Re: Abfrage sehr langsam
Hallo Janbah,
Wie groß ist denn die Datenbank insgesamt? Bedenke, dass sie komplett in den Arbeitsspeicher geladen werden muss. Evt. ist dort auch ein Engpass zu sehen? Die *.odb Datei ist eine gezippte Datei - ausgepackt also noch um einiges größer.
Da es sich ja doch um eine wichtige Datenbank für das Unternehmen / Büro handelt, würde ich auf eine richtige Datenbank (MariaDB, PostgreSQL oder so) Wechseln un die Daten dort hin auslagern. hätte diverse Vorteile;) UNd Abfragen würde dann vom DBMS abgearbeitet - und das ist sicher performer als die eingebaute HSQLDB.
Die Abfrage selbst erscheint mir in Ordnung - die würde ich so auch schreiben;)
Viele Grüße
Tom
ich fürchte, damit wirst Du leben müssen. Filedatenbanken sind leider keinesfalls so perform wie "echte" Datenbank-Managementsysteme - und bei 4000 Datensätzen...Nur dauert die Abfrage bei den bis kjetzt knapp 4000 Datensätzen knapp 10 Sekunden.
Wie groß ist denn die Datenbank insgesamt? Bedenke, dass sie komplett in den Arbeitsspeicher geladen werden muss. Evt. ist dort auch ein Engpass zu sehen? Die *.odb Datei ist eine gezippte Datei - ausgepackt also noch um einiges größer.
Da es sich ja doch um eine wichtige Datenbank für das Unternehmen / Büro handelt, würde ich auf eine richtige Datenbank (MariaDB, PostgreSQL oder so) Wechseln un die Daten dort hin auslagern. hätte diverse Vorteile;) UNd Abfragen würde dann vom DBMS abgearbeitet - und das ist sicher performer als die eingebaute HSQLDB.
Die Abfrage selbst erscheint mir in Ordnung - die würde ich so auch schreiben;)
Viele Grüße
Tom
Unterstützer LibreOffice, zertifizierter Trainer und Berater
Bücher: LibreOffice 6- Einstieg und Umstieg
Makros Grundlagen - LibreOffice / OpenOffice Basic
Bücher: LibreOffice 6- Einstieg und Umstieg
Makros Grundlagen - LibreOffice / OpenOffice Basic
Re: Abfrage sehr langsam
Hallo,
vielen Dank für die schnelle Antwort.
Dann weiß ich wenigstens Bescheid und werde mich tatsächlich mal daran begeben die Daten in eine "richtige" Datenbank auszulagern.
Viele Grüße,
Jan
vielen Dank für die schnelle Antwort.
Dann weiß ich wenigstens Bescheid und werde mich tatsächlich mal daran begeben die Daten in eine "richtige" Datenbank auszulagern.
Viele Grüße,
Jan
Re: Abfrage sehr langsam
Hallo janbah,
deine Frage hat meinen Ehrgeiz geweckt. Da ich aus eigenen Pojekten weiß, das die Funktion DATEDIFF viel Rechenleistung in Anspruch nimmt, und man sie hier eigentlich nur deshalb einsetzt, weil die HSQL 1.8.10 die Funktion DATEADD nicht unterstützt, habe ich mir etwas anderes ausgedacht:
Anbei die Datei. Gruß R
EDIT: Habe die Datei noch einmal getauscht, es war ein Fehler in qKalender
EDIT2: Wenn man die Abfrage qKalender durch folgenden Code ersetzt, kann man auf die Tabelle T_Z verzichten
EDIT3: Habe noch eine einfachere Abfrage für das Datum vor einem Jahr gefunden, ein 29. Februar wird zum 1. März:
deine Frage hat meinen Ehrgeiz geweckt. Da ich aus eigenen Pojekten weiß, das die Funktion DATEDIFF viel Rechenleistung in Anspruch nimmt, und man sie hier eigentlich nur deshalb einsetzt, weil die HSQL 1.8.10 die Funktion DATEADD nicht unterstützt, habe ich mir etwas anderes ausgedacht:
- In der simplen Tabelle T_Z stehen Zahlen von 1 bis 31.
- Die Abfrage q_Kalender kann jetzt benutzt werden, um jeglichen Kalender zu erzeugen, ich habe durch die Bedingungen das Abfrageergebnis von q_Kalender auf den Tag vor einem Jahr, also genau eine Zeile beschränkt.
Code: Alles auswählen
M.Z = MONTH(CURRENT_DATE) AND D.Z = CASEWHEN(DAY(CURRENT_DATE)=29,28,DAY(CURRENT_DATE))
- Dieses Datum benutze ich nun in der Abfrage q_letztesJahr_F3K um die Daten des letzten Jahres zu filtern, kein DATEDIFF !
- In der letzten Abfrage q_mtl_Übersicht_F3K findest du das Ergebnis, vergleichbar mit deinem, nur leere Zeilen fehlen.
Anbei die Datei. Gruß R
EDIT: Habe die Datei noch einmal getauscht, es war ein Fehler in qKalender
EDIT2: Wenn man die Abfrage qKalender durch folgenden Code ersetzt, kann man auf die Tabelle T_Z verzichten
Code: Alles auswählen
SELECT
CAST(
CASE
WHEN ( DAY( CURRENT_DATE ) = 29 AND MONTH( CURRENT_DATE ) = 2 )
THEN '' || YEAR( CURRENT_DATE ) - 1 || '-02-28'
ELSE '' || YEAR( CURRENT_DATE ) - 1 || RIGHT( TO_CHAR( CURRENT_DATE, 'YYYY-MM-DD' ), 6 )
END
AS DATE ) "Datum"
FROM
"INFORMATION_SCHEMA"."SYSTEM_TABLES"
WHERE
"TABLE_NAME" = 'SYSTEM_VIEWS'
Code: Alles auswählen
SELECT
CAST(
REPLACE(CURRENT_DATE, YEAR(CURRENT_DATE), YEAR(CURRENT_DATE)-1)
AS DATE) AS "Datum"
FROM
INFORMATION_SCHEMA.SYSTEM_TABLES
WHERE
TABLE_NAME = 'SYSTEM_VIEWS'
- miniKasse MMove 1.0.6 Base Videotutorial
- Windows 10: AOO, LO Linux Mint: AOO, LO
Re: Abfrage sehr langsam
Hallo F3K Total,
ohh - ich hatte nicht mehr mit einer "Lösung" gerechnet und mich erstmal anderen Problemen zugewendet und deshalb deine Antwort erst heute entdeckt. Vielen Dank erstmal für deine Mühe, aber "leider" bin ich jetzt erstmal für zwei Wochen im Urlaub und kann das Ergebis nicht sofort testen. Ich werde das aber nachholen sobald ich wieder da bin.
Viele GRüße,
Jan
ohh - ich hatte nicht mehr mit einer "Lösung" gerechnet und mich erstmal anderen Problemen zugewendet und deshalb deine Antwort erst heute entdeckt. Vielen Dank erstmal für deine Mühe, aber "leider" bin ich jetzt erstmal für zwei Wochen im Urlaub und kann das Ergebis nicht sofort testen. Ich werde das aber nachholen sobald ich wieder da bin.
Viele GRüße,
Jan