Hallo Gert,
ich danke dir für deine Antwort. Auch wenn diese nicht wirklich auf mein Problem eingeht. Die Performance von Base ist nun mal sehr schlecht, falls man Tabellen mit vielen Tausenden von Datensätzen arbeitet. Öffne ich z.B. die selbe Tabelle zur Ansicht in SQL Workbench/J auf der selben Testmaschine, dann kann ich darin fast flüssig, ohne störende Pausen navigieren. Abfragen gestalten sich ebenso unproblematisch. SQL Workbench/J ist sogar in Java geschrieben. *Hust* von wegen Java sei langsam. Da ich viel mit Java zu tun habe und früher C++ programmieren gelernt habe, vermute ich, dass die Entwickler von Base einige gravierende Designfehler gemacht haben. Evt. werden die ResultSets komplett zwischengespeichert und anschließend werden die Daten ausgegeben. Es würde mehr Sinn machen nur den sichtbaren Bereich an Daten zu laden, zu cachen und darzustellen. Anders kann ich mir diese Zeitverzögerung nicht erklären. Ich werde demnächst mal die Vor-Beta von OOo 3.0 installieren und das Problem darin untersuchen.
Weiterhin, gehe ich nicht davon aus, dass ein Wechsel der Datenbank viel Abhilfe schaffen würde. Wobe ich demnächst eben dieses auch untersuchen werde.
Gert Seler hat geschrieben:
der PC sollte schon 2GB oder 3GB RAM beinhalten (wenn möglich), die Preise für RAM_Speicher sind (noch) im Keller.
Ich hoffe, dass das ein schlechter Scherz war. Das beschriebene Testsystem ist vermutlich leistungsfähiger, als 80% aller Bürorechner und eignet sich hervorragend für solche "kleine" Aufgaben. Wir reden hier von 140.000 bis wirklich max. 200.000 Datensätzen, nicht von 10 oder 20 Mio.
Wenn ich pro Datensatz sehr sehr großzügig von 1 KB ausgehe, sind es max 130 MB, die auf der Festplatte(!) verfügbar sein müssen, tasächlich sind es ca. 32 MB, wenn die .data Datei defragmentiert wurde. Auf hsqldb.org ist ein Anwendungsfall dokumentiert, in dem 4 Mio Datensätze importiert werden und die VM sich mit 16 MB RAM begnügen darf - soviel zur technischen Machbarkeit.
Selbst wenn ich die Ansicht der Tabellendaten in Base auf einem aktuellen Mac Pro öffnen würde, wäre das Ergbnis nicht so wie es sein sollte.
Gert Seler hat geschrieben:
Zur externe DB wäre "MySQL" (jetzt bei Sun.com) oder "PostgreSQL" geeignet.
Die Einarbeitungszeit sollte nicht unterschätzt werden.
Der Treiber "JDBC" für "MySQL" oder "PostgreSQL" sollte installiert werden.
Bitte vorher diese Seite lesen :
http[//www.little-idiot.de/mysql/mysql-189.html
Habe früher recht viel mit MySQL gearbeitet, bis die alte Firma die Lizenz geändert hat. Seit 3 Jahren arbeite ich mit PostgreSQL, mittlerweile laufen die Anwendungen auf fast 100 Systemen. Von der Performanz des DBMS bin ich begeistert, aber es hat schon Wochen gedauert, bis ich alle Systemeinstellungen, Abfragen und Prozeduren optimiert habe.
Und trotzdem glaube ich nicht, dass der Einsatz von PostgreSQL bei dem Problem mit Base viel helfen würde. Wie gesagt, ich gehe mittlerweile davon aus, dass die Ansicht mies implementiert worden ist. Ich hätte schon Spaß daran, mir den entsprechenden Code mal näher anzuschauen. Aber bei der so gut wie nicht existenten Dokumentation der entsprechenden Module, würde die Einarbeitung viel zu lange dauern.
Gert Seler hat geschrieben:
Spezielle Abfragen vorausgesetzt.
Wird "Win_Xp" oder "Vista" eingesetzt den "Cache" größer wählen (bitte testen) vielleicht hilft das auch.
Die Ladezeit sollte dann erheblich kürzer sein. Überlegen, ob eine "Netzwerk_Installation" für die Zukunft
angebracht ist.
Welche Abfragen meinst du?
Ich habe eigentlich nur nach der Ansicht des Tabelleninhaltes gefragt (Doppelklick auf "TabellenName").
Welchen Cache meinst du nun?
Den Arbeitsspeicher von PostgreSQL, dann s.o.
Oder doch den 2nd level cache, weil mein Testsystem nur 256 KB hat und die Prozessorpreise auch so niedrig sind?
Schöne Grüße
Alex
PS: Mein FF ist seit heute anscheinend auch von dem � (Raute mit Fragezeichen) Problem betroffen.