Optimierung Datenbankzugriff Firebird

[IBExpert]

Zitat von sx2008:

Deine Schlussfolgerung in Zukunft ALLE Datasets zur Laufzeit zu erzeugen ist aber auch nicht die Lösung.
Du verschenkst damit Entwicklungszeit und erhöhst die Menge des Sourcecodes.
(je mehr Sourcecode, umso mehr Fehlermöglichkeiten gibt es)

Das schöne ist bei meiner Vorgehensweise, das ich kaum Sourcecode habe und schon gar nicht wegen einer neuen Tabelle neuen Source ergänzen muss. Ich hatte mal vor ewigkeiten auf einer Entwicklerkonferenz dafür ein paar Sessions zum Thema OOP gegeben und das Verfahren in den letzten 13 Jahren noch mal deutlich weiterentwickelt. Damals hatte ich durch einen Quelltextgenerator einfach zu jeder Tabelle in der DB eine eigene Unit erzeugt, in der dann eine von einer Basisklasse abgeleitete Klasse erzeugt wurde, die dann sämtliche Datenbankoperationen einheitlich abgewickelt hat und nebenbei auch noch dynamisch passende TWincontrols auf jeden beliebigen Container (TPanel, TScrollbox o.ä.) erzeugen konnte.

Erst auf der Ebene der Basisklasse habe ich dann die konkrete Implementation angesprochen, also ob das TQuery, TIBOQuery, TICQuery oder was auch immer war, solange es eine Dataset Ableitung war. Ich bekomme immer noch Tränen in den Augen, wenn ich sehe, wie viele Kundenprojekte zum Beispiel mal mit IBObjects realisiert wurden und wo man sich in ewige Abhängigkeit davon begeben hat. Wenn ich in einer Unit nur den Konstrutor auf ein andere Klasse portieren muß dauert das ggf. nur wenige Minuten, wenn ich aber in 200 Datenmodulen 5000 Datasetableitungen mit 50000 TField Definitionen anpassen muß, dann sieht das schon ganz anders aus, insbesondere wenn es auf einmal gewisse TFieldklassen, -properties oder events gar nicht mehr pder mit anderer Implementation gibt.

Der Quelltextgenerator selbst hat danach dann auch noch (sofern nicht schon vorhanden) von dieser Klasse noch mal eine Ableitung erstellt, in der ich dann Methoden überschreiben konnte und völlig andere Implemetationen für komplexere Aufgaben umsetzen konnte.

Der Quelltextgenerator hat neben den Objektklassen auch noch automatisch diverse include files erzeugt, die ich dann im eigentlichen Projekt eingebaut habe. Da der meiste Sourcecode aus dem Quelltextgenerator erzeugt wurde war dieser per Definition fehlerfrei. Ob der dann das gemacht hat, was er machen sollte, lag am Sourcecode vom Quelltextgenerator, aber in einem großen Projekt mit ca. 800 Tabellen musste für die Kompatibilitätsschicht zwischen Firebird und IBM AS/400 iSeries (oder wie auch immer die Kiste jetzt heißt) nach einem Update auf der AS/400 Seite und der Umstellung von Delphi/400 auf ODBC ziemlich viel geändert werden. Das wurde aber nur ein einer klasse exemplarisch manuell gemacht, bis es lief und dann der Quelltextgenerator angepasst, damit der die neuen Strukturen erzeugt. Die restlichen 799 Klasse dauerten danach weniger als eine Minute. Der Quelltextgenerator war übrigens eine ganz gruselige Implementation (TForm mit TMemo, TButton, einer TxDatabase, einer TxQuery) und einem endlosen OnClick Event, mit dem die gefundenen Metadaten aus der DB in Delphi kompatiblen Quellcode umgewandelt wurde. Einige werden sich evtl noch dran erinnern ...

Das klassische RAD Prinzip von Delphi ist zwar am Anfang sehr produktiv, aber bei Projekten, die mehrere Jahre auch in größeren Teams entwickelt werden sollen, kann das schon mal gewaltig nach hinten losgehen. Ob man sich mal vor Jahren zum Einsatz von IBObjects entschlossen hat, Orpheus oder Turbopower Krams eingebaut hat oder was auch immer vor einigen Jahren mal angesagt war: Die konkrete Implementation an zigtausend Stellen im eigenen Quellcode lässt sich meistens mit Mühe und Suchen/Ersetzen noch lösen, der ganze Kram in den DFMs ist dann aber oft schon mit dem ersten Öffnen der Formulare mit fehlender oder falschen Komponentenversion hoffnungslos vergurkt.

Ich habe im Laufe der Jahre diverse Softwarehäuser beraten, die oft auch meine Architektur übernommen haben und von denen habe ich viele Rückmeldungen, das dadurch die Fehler der Vergangenheit endlich hinter sich lassen konnten.

Mittlerweile läuft das bei mir ohne eigene Units pro Tabelle über eine im Laufe der Jahre entwickelte Basisklasse, bei der alle Information zu jeder Tabelle bei ersten Zugriff im Client gecacht werden. Für lesen und schreiben der Daten werde eigene SQLs automatisch erzeugt oder, sofern vorhanden, nach bestimmten Namenskonvention vorhandene SPs benutzt.

In meinem Modell ist die Datenbankstruktur Basis für alles andere, ich weiß aber auch, das viele das gerne andersherum lösen. Mein Vorteil ist, das meine Implementation mit völlig unterschiedlichen Datenbanken auch völlig unterschiedliche Anforderungen umsetzen kann, ich also für jeden Kunden individuell customizen kann. Ich glaub bei der Entwicklungszeit kann ich mit anderen Modellen sehr gut mithalten, die grundlegende Basis ist war nicht in 5 Tagen entwickelt, wenn man die dann aber stehen hat, geht es extrem fix.

Mehr Komponenten bedeutet nicht zwangsläufig weniger Quellcode, umgekehrt aber auch nicht. Der ganze Bereich der Programmierung wäre aber auch extrem langweilig, wenn es immer nur die "eine Lösung" geben würde.

[IBExpert]

Zitat von Perlsau:

Auf die meisten Tabellen werden beim Start Locate-Methoden angewandt, um die zuletzt bearbeiteten Datensätze für den Anwender sofort sichtbar zu machen. Auch das werde ich nochmal überdenken, denn eigentlich benötigt der Anwender nur zwei oder drei Tabellen, mit denen er wirklich ständig arbeitet. Das sollte auch etwas Geschindigkeit beim Start bringen.

Locate ist meistens ein blödes Verfahren, weil eben alle Records zum Client geliefert werden, bis derjenige kommt, den du haben wolltest. Das entschidet aber der Client. Ist bei Filterproperties auch oft so ähnlich. Da kannst du auch bei der Auskunft anrufen und dir das Telefonbuch komplett vorlesen lassen. Bei kleinen Datenmengen ist das egal, aber 300000 oder 1000000 Records sind keine kleine Datenmenge mehr.

Zitat von Perlsau:

Hab leider nur die Personal-Version von IBExpert. Aber die Database-Properties kann ich mir natürlich anzeigen lassen: Unter Buffer steht Pages auf 90 und KB auf 1440. Hab jetzt mal den Wert auf 10000 kb erhöht, dabei entstehen 625 Seiten und der Sweep-Interval steht auf 20000.
...

Leider weiß ich nicht mehr genau, welche Firebird-Version (v2.5) ich installiert hatte, aber ich glaube mich zu erinnern, daß es er Classic-Server war. IBexpert schreibt mir das heraus, wenn ich die Servereigenschaften abfrage:
Server Version: WI-V2.5.2.26539 Firebird 2.5
Server Implementation: Firebird/x86/Windows NT
Service Version: 2

Das sieht also nach Classic aus (oder Superclassic). Trag mal da wo jetzt 625 steht 5000 ein, dann müsste rechts 80000kb stehen (das wären 80 MB cache pro Connection, der Wert wird auch in der DB gespeichert). Wenn du keinen konkreten Grund hast, dann am besten noch mal deinstallieren und als Superserver neu installieren, das hat für jemanden, der nicht im Thema drin ist, meistens Vorteile, weil beim Superserver solange noch mindestens eine Connection geöffnet ist alle Daten im Cache bleiben und jeder Client die Abfragen wenn möglich aus dem Cache beantwortet bekommt. Je langsamer die festplatte, um so größer die Vorteile des Superservers. Beim Classic hat jede Connection immer einen eigenen Cache, das macht nur Sinn bei extrem schnellen Datenträgern, z.B. Enterprise SSDs. Beim Superserver kannst du den Cache auch auf z.B. 20000 setzen. Sweep Interval ist dafür erst mal nicht relevant.

Wenn du noch mehr Infos zu Firebird brauchst und dir mal hier und da Zeit dafür nehmen kannst, dann würde ich mal so nach und nach die Videos auf http://www.youtube.com/user/IBExpertise oder im IBExpertLive Player (http://ibexpert.net/ibe/index.php?n=Doc.IBExpertLive) anschauen, da sind auch einige deutschsprachige Schulungen von uns dabei.

[IBExpert]

Zitat von Perlsau:

Hab leider nur die Personal-Version von IBExpert

kann man ändern, gibt es für facebook likes als Sonderpreis für 99 €
https://www.facebook.com/IBExpertise...51161908249538

[tsteinmaurer]

Zitat:

Locate ist meistens ein blödes Verfahren, weil eben alle Records zum Client geliefert werden, bis derjenige kommt, den du haben wolltest

Um Mißverständnissen vorzubeugen. Das war zu Zeiten der BDE. IBObjects zum Beispiel ist da viel cleverer. IBDac eventuell auch. Ist mit der Trace API nun alles schön transparent, was da von den Zugriffskomponenten teilweise verbrochen wird. Aber das Thema Trace API wurde ja bereits erwähnt ...

[Perlsau]

Den Übeltäter für die langen Wartezeiten beim Starten meiner Anwendung habe ich jetzt eindeutig ausgemacht: Er heißt Sortieren. Nachdem ich alle Zuweisungen an IndexFieldNames – jenes Property der IBDac-Query-Komponenten, das für die Sortierung zuständig ist – entfernt hatte, warte ich ca 2 Sekunden darauf, daß die Anwendung zur Verfügung steht (ohne Ladezeit, da sind's dann schätzungsweise 3,5 Sekunden, also nur für den Aufbau der Anwendung im Speicher). Sobald ich jedoch sortieren lasse, ist die Geschwindigkeit dahin, ganz besonders bei meiner größten Tabelle mit derzeit um die 300.000 Einträgen und etlichen Abhängigkeiten. Eigentlich wird ja nicht die eigentliche Tabelle sortiert, sondern lediglich das View, das ich von dieser Tabelle in der DB angelegt habe. Die Sortierung des Views geht weitaus schneller als die der eigentlichen Tabelle mit ihren Lookup-Feldern. Leider war es mir bislang nicht möglich, die Sortierung des Vies zu beschleunigen, sie benötigt noch immer ca. 26 sec. Und da noch ca. 700.000 Einträge folgen werden, muß ich leider auf die Sortierung dieses speziellen Views beim Programmstart verzichten. Immerhin geht die Sortierung mittels Zuweisungen an IndexFieldNames mehr als 10 mal schneller als mittels Manipulation der Order-Klausel im Select-Befehl, die dauerte nämlich 157 Sekunden.

[Perlsau]

Wenn ich die Sortierung ganz weglasse, benötigt der Start noch immer ca. 11 Sekunden. Kommentiere ich auch noch das Lokalisieren der zuletzt angezeigten Datensätze aus (locate), bin ich bei 46 Millisekunden Startzeit. Ich werde mich also darauf beschränken, die Haupttabelle, die noch gar nicht implementiert ist, zu sortieren und lokalisieren. Das werden bei einem Durchschnittsanwender sicher nicht mehr als 10- bis 20tausend Einträge werden ...

[mkinzler]

Und wenn du eine Query nimmst und im SQL-Statement sortierst?

[Perlsau]

Zitat von mkinzler:

Und wenn du eine Query nimmst und im SQL-Statement sortierst?

Hab ich im Post #15 bereits dargestellt:

Immerhin geht die Sortierung mittels Zuweisungen an IndexFieldNames mehr als 10 mal schneller als mittels Manipulation der Order-Klausel im Select-Befehl, die dauerte nämlich 157 Sekunden.

Ich hab ja jetzt fast nur noch Queries statt der Table-Komponenten, die bei IBdac im Grunde Datasets sind, wenn ich die Dokumentation richtig verstanden habe. Nur für die paar Tabellen, die sowieso nicht vom Anwender erweitert werden, wie Geschlecht, Anrede usw., hab ich die Tables gelassen. Die Sortiermöglichkeit in der Anwendung bleibt natürlich erhalten, nur überlasse ich es dem Anwwender, ob er die Sortierungen abspeichern will, eventuell sogar mit einer Warnung, daß das die Ladezeit des Programms enorm verzögert. Ich weiß nicht, wie andere das machen, und ich hab auch gerade kein Beispiel zur Hand, bei dem das Sortieren und Lokalisieren die Ladezeit der Anwendung nicht dermaßen vergrößert. Vielleicht ist das ja alles ganz normal

[Perlsau]

Zitat von IBExpert:

Wenn du noch mehr Infos zu Firebird brauchst und dir mal hier und da Zeit dafür nehmen kannst, dann würde ich mal so nach und nach die Videos auf http://www.youtube.com/user/IBExpertise oder im IBExpertLive Player (http://ibexpert.net/ibe/index.php?n=Doc.IBExpertLive) anschauen, da sind auch einige deutschsprachige Schulungen von uns dabei.

Da ist nur ein Video auf deutsch, nämlich das mit der Shadow-Datei. Die anderen sind allesamt auf englisch. Lesen und schreiben geht bei mir einigermaßen, aber englisch verstehen, noch dazu wenn schnell gesprochen wird, macht mir Schwierigkeiten.
Naja, ich werd' mich dennoch irgendwie durchwurschteln ...

[IBExpert]

Moin,

die deutschen Videos sind im IBExpertLive, auf Yourtube ist wirklich nur eins auf deutsch