sehr langsames Formular

[Geotrans]

Bei meinem Formular "factory" dauert es ca 15 Sec. beim wechseln des Datensatzes bis alle Daten angezeigt werden. Das liegt sicher an den berechneten Feldern "Anzahl der Fabriken", "Produktionsmenge" und "Verbrauchsmenge", den beim Formular "factory ohne Berechnung" geht es deutlich schneller.
1.) ich habe hier viewtopic.php?f=8&t=53613&p=202661&hili ... am#p202661 gelesen, das womöglich die Java Version das Problem ist. Ich benutze Opensuse 12.1 mit Java 1.6.0.u29-0.2.1. Ist nach wie vor die 1.6.0_22 die aktuell beste Wahl?
2.) geht es auf anderen Rechnern deutlich schneller?
3.)wie stark wird sich die "Ladezeit" schätzungsweise verändern wenn weitere Daten dazu kommen (max. 200)? Momentan handelt es sich ja nur um 7 Datensätze.
4.) Gibt es noch alternativen oder Verbesserungen die berechneten Werte anzuzeigen um so die Performance zu erhöhen?

[juetho]

Bei mir dauert es etwa fünf bis acht Sekunden: Win7 (siehe Signatur), LibO 3.6.3.2 (Build ID: 58f22d5), Java JRE6 (1.6.0_31).

200 Datensätze dürften nicht wesentlich schlechtere Ergebnisse liefern.

Normalerweise gibt es Verbesserungen durch: Datenbank normalisieren, Fremdschlüssel einrichten, Indizes einrichten (für alle Spalten, nach denen wiederholt selektiert werden soll, also die in WHERE oder GROUP BY benutzt werden), VIEWs benutzen statt adhoc-Abfragen. Eine "richtige" Datenbank bietet auch Ausführungspläne an (EXPLAIN o.ä.), deren Analyse eine bessere Abfrage liefern kann.

Ob bei deinen Anforderungen diese Möglichkeiten noch etwas bringen, ist zweifelhaft; du hast schließlich schon viel versucht. Jürgen

[Geotrans]

Hallo Jürgen,
Danke Dir ganz herzlich für Deine Tipps und Einschätzungen!
Für Views sehe ich leider keine Möglichkeit, oder habe ich da was übersehen oder auch noch nicht verstanden?

Gruß, Georg

[juetho]

Für Views sehe ich leider keine Möglichkeit,

Grundsätzlich bietet auch HSQL die Möglichkeit von VIEWs, z.B. über Extras > SQL:

Code: Alles auswählen

CREATE VIEW "vfactory" AS
SELECT * FROM "factory"

Verschiedene Verknüpfungen, die immer wieder auftreten, können hier "fest" zusammengebaut werden. Gleiches gilt für deine Abfragen. Wenn ich die Arbeitsweise von OO richtig verstanden habe, werden Abfragen von Base verwaltet (also von der Benutzeroberfläche), während eine VIEW in der Datenbank (also fest) gespeichert wird.

Grundsätzlich könntest du also jede Abfrage durch eine VIEW ersetzen. Ein Problem könnten variable Parameter (vor allem in einer WHERE-Klausel) sein. Solche Variablen sind bei VIEWs nicht möglich. Stattdessen muss die betreffende Spalte in der Auswahlliste erscheinen, damit beim Aufruf der VIEW eine entsprechende Einschränkung möglich ist.

Du könntest zunächst einmal eine der "innersten" Abfragen durch eine VIEW ersetzen, um das Prinzip zu verstehen. Nach jedem neuen CREATE VIEW ist Ansicht > Tabellen aktualisieren zu wählen; danach steht die VIEW in der Liste der Tabellen. Ebenso wird beim Report Builder (und auch bei Formularen) eine VIEW wie eine Tabelle verwendet.

Gruß Jürgen

PS. Für Änderungen musst du ausprobieren, was möglich ist: CREATE OR ALTER VIEW (das wäre das schönste) oder direkt mit ALTER VIEW oder ob es über DROP VIEW und anschließendes CREATE VIEW gehen muss.

[F3K Total]

Hi,
nur zur Info:
Views kann man auch mit GUI erzeugen, siehe unter Tabellen:

View.png (18.73 KiB) 2350 mal betrachtet

Gruß R

[juetho]

So kann es gehen:

Views kann man auch mit GUI erzeugen, siehe unter Tabellen:

View.png

Die Mischung zwischen deutscher Übersetzung der englischen GUI (Entwurfsansicht), deutscher Übersetzung von Fachbegriffen (wie den Eigenschaften im Formular-Designer) und wiederholter Verwendung ähnlicher Begriffe (hier: "Ansicht erstellen" bei Tabellen und "Abfrage in SQL-Ansicht erstellen") hat mich übersehen lassen, dass "Ansicht" auch eine deutsche Übersetzung von VIEW ist.

@Georg
Du solltest (wenn du VIEWs probierst) trotzdem besser deine bisherigen Ergebnisse als SQL-Code übertragen, weil in den Verknüpfungen viele Bedingungen zusammengefasst sind. Jürgen

[Geotrans]

Ganz Herzlichen Dank für die vielen Tipps.
Habe die Abfragen durch Views ersetzt und tatsächlich hat sich die Geschwindigkeit mit der sich das Formular öffnet deutlich erhöht . Leider ist die Aktualisierung der berechneten Werte noch eher etwas zufällig.

PS. Für Änderungen musst du ausprobieren, was möglich ist: CREATE OR ALTER VIEW (das wäre das schönste) oder direkt mit ALTER VIEW oder ob es über DROP VIEW und anschließendes CREATE VIEW gehen muss.

Ich vermute es liegt daran, das ich dies noch nicht umgesetzt habe. Ich habe noch nicht begriffen wo und wie ich diese befehle eingeben oder Anwenden muß. Wäre für einen weiteren Tipp sehr Dankbar.
Habe mal die beschleunigte Version angehängt (Formular "factory_A").
Gruß, Georg

[juetho]

Es freut mich sehr, dass der Tipp mit den VIEWs die Geschwindigkeit erhöht hat. Dies war mir grundsätzlich klar, aber ich konnte nicht abschätzen, welche Maßnahme zu spürbaren Verbesserungen führen würde.

Leider ist die Aktualisierung der berechneten Werte noch eher etwas zufällig.

PS. Für Änderungen musst du ausprobieren, was möglich ist: CREATE OR ALTER VIEW ...

Ich vermute es liegt daran, das ich dies noch nicht umgesetzt habe. Ich habe noch nicht begriffen wo und wie ich diese befehle eingeben oder Anwenden muß.

Die Auswahl bzw. Anwendung eines dieser Befehle hat höchstens indirekt etwas mit der "zufälligen Aktualisierung" der Werte zu tun.

Bei einer VIEW werden nicht irgendwelche ausgewählten Daten zwischengespeichert und (etwa aus einem Cache) geholt. Bei jedem neuen Aufruf einer VIEW werden die Daten nach dem aktuellen Stand neu zusammengesucht. Wenn die Aktualisierung etwas zufällig erscheint, liegt das vermutlich eher daran, dass ein refresh oder reload fehlt (z.B. Handbuch S. 233 f.).

Die genannten Befehle sind wie folgt zu verwenden: Wenn du nach F3Ks Vorschlag arbeitest, sind sie irrelevant; dann baut Base die Befehle aus den Eingaben zusammen. Wenn du nach meinem Vorschlag mit Extras > SQL eine VIEW per SQL-Befehl definierst, ist beim ersten Versuch selbstverständlich CREATE VIEW zu verwenden. Nur selten genügt ein erster Versuch (genauso wie in deinen komplexen SELECTs). Dann muss die VIEW unter demselben Namen geändert werden; dafür ist ALTER VIEW vorgesehen. Mit der Variante CREATE OR ALTER muss man nicht überlegen, ob die VIEW schon einmal gespeichert wurde. Wenn man Pech hat, kennt ein DBMS den ALTER-Befehl überhaupt nicht; dann muss zuerst mit DROP VIEW die alte (falsche) Definition gelöscht werden, bevor sie neu angelegt werden kann.

Könnte es sein, dass ich dich noch nicht auf die Einführung in SQL hingewiesen habe? Dort findest du ausführliche Erläuterungen. Gruß Jürgen