Rave-Report mit Records aus zwei Datenbanken

[Perlsau]

Hallo Leute

Seit Tagen versuche ich, in einem Rave-Report (D2009 Rave 7.6.2) Resultate aus zwei verschiedenen Firebird-DBs darzustellen. Hintergrund: Für eine Anwendung wurde ein Zusatz-Modul entwickelt, das erweiterte Informationen zu Datensätzen aus der Primär-Datenbank bereitstellt. Die Auslagerung in eine zweite DB schien mir deshalb sinnvoll, weil die Zusatz-DB enorm groß ist (über 1 GB) und sich höchstens einmal pro Monat ändert. Das Sichern (Backup) der Primär-DB geht daher viel schneller, wenn die Zusatz-DB ausgelagert ist. Zudem benötigt nicht jeder Anwender diese Zusatz-DB. Die entsprechenden Funktionen werden in der Anwendung erst bereitgestellt, wenn die Zusatz-DB, die bei Bedarf zusätzlich zu erwerben ist, zur Verfügung steht.

In besagter Tabelle der primären DB gibt es eine Id-Spalte, die auf den jeweiligen Record in der Zusatz-DB verweist. Nun muß ich einen Report erstellen, der diese Zusatz-Infos beinhaltet. Geht das überhaupt und wenn ja, wie sähe da das Konzept aus? Was ich bereits versucht habe:

Zusätzliche Lookup-Felder im Query der Haupttabelle (Primär-DB) erstellt und entsprechend verbunden. Die Anzeige im Rave-Report wird zwar korrekt dargestellt, doch benötigt die Berechnung unheimlich lange, was ich nachvollziehen kann, da ja für jedes Feld erst nachgeschlagen werden muß. Dieses Vorgehen verzögert zusätzlich auch die Darstellung der Haupttabelle in einem DBGrid, wo ich die Zusatzfelder aber gar nicht benötige. Und ein spezielles View in der primären DB zu erstellen wird wohl auch nicht möglich sein, da es sich ja um eine andere Datenbank handelt. Kann man nicht irgendwie die Lookup-Felder bei Bedarf deaktivieren? Oder muß ich hier eine zusätzliche Query-Komponente einsetzen?

[IBExpert]

DHast du schon mal versucht, den Report mit einem execute block zu realisieren, in dem du dann per execute statement on external die daten der zweiten Datenbank holst. Aus der Sicht deiner Reportengine sollte das transparent sein, wenn die mit einem execute block in der Query klar kommt, den du dann dort statt der Select Anweisung einträgst. Alternativ geht auch der Weg über Stored procedures, auch da geht execute statement on external, setzt aber fb25 voraus.

[Bernhard Geyer]

1 GB und Groß - aber ich glaube das ist eine anderes Thema.

Kannst du die Tabellen der zweiten DB nicht per Linked Table (Weiß jetzt nicht wie das Richtig Wort hierfür bei Firebird heißt) einbinden so das es für den ReportGenerator so aussieht als würden alle Tabellen aus einer DB kommen.

[mkinzler]

Firebird erlaubt (bisher) nur in PL den Zugriff auf eine andere Datenbank. Linked Tables o.ä. werden m.W. nicht unterstützt.

[Perlsau]

Zitat von IBExpert:

Hast du schon mal versucht, den Report mit einem execute block zu realisieren, in dem du dann per execute statement on external die daten der zweiten Datenbank holst. Aus der Sicht deiner Reportengine sollte das transparent sein, wenn die mit einem execute block in der Query klar kommt, den du dann dort statt der Select Anweisung einträgst. Alternativ geht auch der Weg über Stored procedures, auch da geht execute statement on external, setzt aber fb25 voraus.

Hallo Holger, das habe ich noch nicht versucht, denn mir ist noch nicht so recht klar, was ein execute statement on external genau ist.

Zitat von Bernhard Geyer:

1 GB und Groß - aber ich glaube das ist eine anderes Thema.

Klar ist 1 GB nicht wirklich viel. Doch im Vergleich mit den kaum 100 MB der Primär-DB, die aber auch mit der Zeit wächst, ist da schon ein Größenunterschied.

Zitat von Bernhard Geyer:

Kannst du die Tabellen der zweiten DB nicht per Linked Table (Weiß jetzt nicht wie das Richtig Wort hierfür bei Firebird heißt) einbinden so das es für den ReportGenerator so aussieht als würden alle Tabellen aus einer DB kommen.

Von Linked Table hab ich noch nie was gehört – bin ja auch nicht gerade der herausragende Firebird-Honk Das Problem besteht nicht darin, überhaupt an die Informationen heranzukommen, sondern die Verarbeitungsgeschwindigkeit zu erhöhen. Die Selektion einer Datenmenge mit 85 Records, die ihre Zusatzinfo (5 Lookupfields) aus der anderen DB holen müssen, dauert derzeit gut drei Minuten. Das ist unzumutbar. Für die Reporterstellung wäre das nicht so tragisch, aber beim Filtern und Suchen in der Tabelle, was wesentlich häufiger geschieht als der Report, ist diese lange Zeit schon ärgerlich. Die Reporterstellung selbst dauert dann seltsamerweise nicht mehr so lange, wohl weil die Abfragen aus der Zusatz-DB zu diesem Zeitpunkt bereits erfolgt sind ... vermute ich mal ...

Hintergrund: Beim Einlesen der Daten (Logdateien) hat der Anwender die Möglichkeit, die Zusatzinfos gleich zuzuordnen. Sobald ein Datensatz in der DB gespeichert wurde, wird der passende Datensatz aus der Zusatz-DB herausgesucht und die jeweilige Id in der Haupttabelle der Primär-DB gespeichert. Das geht recht flott, obwohl hierbei zwei Felder verglichen werden müssen. So dauert das Einlesen – wozu auch das Analysieren des Log-Eintrags gehört sowie die Überprüfung, ob ein Eintrag mit demselben Zeitstempel und demselben Dateinamen bereits existiert – von 1500 Einträgen kaum länger als 5 Minuten (geschätzt, nicht gemessen). Ich weiß nicht, woher diese lange Ausführungszeit beim Select-Befehl im Query kommt. Momentan sind in dieser Haupttabelle knapp 310.000 Records, selektiert wird aber das entsprechende View in der Datenbank, weil das sowohl zur Darstellung im DBGrid als auch für den Reportgenerator benötigt wird. Je nach Select-Befehl (hätte ich vielleicht auch mit Filter machen können) dauert es bis zu 10 Sekunden, bis die Daten angezeigt werden. Auch das ist erträglich, müssen doch gegebenenfalls mehrere Spalten überprüft werden. Z.B. filtere mir alles vom 1.12. bis heute raus, das die Datei soundso beinhaltet, mit dieser Domain und jenem Result-Code. Aus den Einstellungen im Filter-Modul wird dann der SQL-Befehl gebastelt. Seit ich nun diese Nachschlagefelder implementiert habe, dauert allein schon das Selektieren unerträglich lange, also bei jeder Änderung des Filters 3 oder mehr Minuten warten, bei größeren Datenmengen auch mal 15 bis 20 Minuten ...

Ich werde mir jetzt erstmal so behelfen, daß ich ein eigenständiges Query für die erweiterte Reporterstellung einsetze und für die Darstellung im Grid einfach die Lookup-Fields weglasse. Heute aber wohl nicht mehr ...

Zitat von mkinzler:

Firebird erlaubt (bisher) nur in PL den Zugriff auf eine andere Datenbank. Linked Tables o.ä. werden m.W. nicht unterstützt.

Was ist PL?

Nachtrag: Dem Reportgenerator dürfte es egal sein, ob die Daten aus einer oder aus mehreren Datenbanken stammen, denn die Daten werden ja über eine TRvDataSetConnection bereitgestellt. Ich bin mir auch nicht sicher, ob die beschriebene Verzögerung tatsächlich mit der Verwendung einer zweiten Datenbank zusammenhängt.

[mkinzler]

Zitat:

denn mir ist noch nicht so recht klar, was ein execute statement on external genau ist.

Ein Abfrage auf eine Tabelle einer anderen Datenbank ( auf dem selben oder anderen Server)

Zitat:

Von Linked Table hab ich noch nie was gehört – bin ja auch nicht gerade der herausragende Firebird-Honk

Gibt es meines Wissens auch in FireBird nicht. Benutzt man z.B. in Access. Auf eine Linked Table kann man wie auf interne Tabellen zugreifen, diese sind aber mit Tabellen in einer anderen Datenbank( -system) verknüpft.

Zitat:

Das Problem besteht nicht darin, überhaupt an die Informationen heranzukommen, sondern die Verarbeitungsgeschwindigkeit zu erhöhen.

Dann integriere die beiden Datenbanken am Besten, den performant wird es sonst (zuminst in FB) nicht.

[IBExpert]

Hier ein Beispiel für ein execute block aus unserer letzten Schulung auf Basis der IBExpert Demo DB.

Der Block läuft in einer DB ab und verbindet sich immer innerhalb der Schleife mit der anderen DB.
Wenn die Daten in der eigentlichen DB bleiben, wäre das sicherlich performanter und 1GB ist noch lange kein
Grund, da was auszulagern, wir nutzen aber genau das Verfahren für sehr große Mengen von PDFs und Bildern,
da kommen pro Jahr gerne mal 100GB zusammen. Die werden dann immer jahresweise in Archivdatenbanken übertragen
und die sind dann nur noch readonly, brauchen daher auch nicht mehr gesichert werden.

Code:

execute block
returns
(customer_name varchar(200),
total_sales numeric(18,2))
as
declare variable customer_id bigint;
begin
  for
    select customer.firstname||' '||customer.lastname, customer.id
    from customer
    into customer_name , customer_id
  do
  begin
    execute statement ('select sum(orders.totalamount) from orders where orders.customer_id=:CUSTOMER_ID')(CUSTOMER_ID:=CUSTOMER_ID)
--    on external 'localhost/3050:d:\fet\db1.fdb'   --wennn es ein anderer FB Server ist, dann so
    on external 'd:\fet\db1.fdb'                    --sonst so, weil schneller, könnte auch der Firebird alias aus der aliases.conf sein
    as user 'SYSDBA' password 'masterke'
    into total_sales;
    suspend;
  end
end

Wenn du die zeile mit "as user ... password ... " weglässt, dann werden die Daten deiner aktuellen Connection genommen

[IBExpert]

Zitat von Bernhard Geyer:

1 GB und Groß - aber ich glaube das ist eine anderes Thema.

Kannst du die Tabellen der zweiten DB nicht per Linked Table (Weiß jetzt nicht wie das Richtig Wort hierfür bei Firebird heißt) einbinden so das es für den ReportGenerator so aussieht als würden alle Tabellen aus einer DB kommen.

Mann kann so was in Firebird über den Umweg Stored Procedure mit execute statement on external und view auf der Stored Procedure und trigger, die den View updatetable machen, umsetzten, ist aber in den seltensten Fällen eine performante Lösung, weil ein select auf dem view nicht mit indizes arbeiten würde, denn die gibt es nur in der anderen DB zu den betroffenen Tabellen. Mit dafür speziell programmierten Zugriffsprozeduren wäre das aber für Enterprise Anwendungen eine sehr gute Lösung auch für extrem große Datenmengen, das ist aber bei 1GB keineswegs gegeben.

[Perlsau]

Ich habe das Problem jetzt so gelöst: Die Struktur mit den zwei Datenbanken habe ich beibehalten. In der Haupt-Datenbank wurde die Ip-Nummern-Tabelle um die Einträge Land, State, PLZ, Stadt usw. erweitert. Nach jeder Aktualisierung der Access-Daten (tägliches Logfile) werden die neu hinzugekommenen IP-Nummern um diese Einträge ergänzt. Gleichzeitig wurde das View in der DB, das alle diese Subtabellen zusammenfaßt, ebenfalls um die neu hinzugekommenen Spalten in der Ip-Nummern-Tabelle erweitert. So kann ich jetzt auch nach Land, State, Stadt etc. suchen und sortieren. Da pro Aktualisierung gewöhnlich zwischen 300 und 500 neue IP-Adressen hinzukommen, hält sich der Zeitaufwand für die Aktualisierung noch immer in erträglichen Grenzen. Damit ist mein Problem gelöst.