Stored Procedure mit Verknüpfung mehrerer Datenbanken

[Jürgen Thomas]

Beim Wechsel von BDE (Paradox und dBase) zu Interbase möchte ich auch umfangreiche Datenänderungen und Auswertungen auf den Server in die Datenbanken legen. Dazu ist es nötig, dass aus der aktiven Datenbank heraus (in der die Stored Procedure liegt, die die Verarbeitung steuert) auf andere Datenbanken zugegriffen wird. Aus den Beschreibungen zu Interbase und aus Büchern kann ich nicht erkennen, dass <b>in einer Stored Procedure ein Database-Connect auf eine andere Datenbank</b> möglich ist. Kann mir jemand einen Tipp geben, wie ich das Verfahren lösen kann?

Für meinen Arbeitsablauf habe ich folgende Situation:<br>
* Die Datenbank POST enthält (prinzipiell) unveränderliche Stammdaten, nämlich PLZ, Ortsnamen und die Art der Verarbeitung.<br>
* Eine oder mehrere Datenbanken ADRESSEN_A, ADRESSEN_B enthalten (unabhängig voneinander) die eigentlichen Adressen.<br>
* Zu jeder ADRESSEN-Datenbank gibt es eine oder mehrere Datenbanken VERSAND_A_1, VERSAND_A_2 usw., die eine bestimmte aktuelle Auswertung für beliebig lange Zeit speichert.

(Die Versand-Datenbanken könnten in die jeweilige Adressen-Datenbank integriert werden. Der Endanwender soll aber freie Hand haben, sich mehrere Versand-Daten aufzuheben. Deshalb ist eine Trennung praktischer, aber nicht notwendig.)

Die Auswertung soll mit den folgenden Schritten beginnen. Nach meiner Idee soll alles innerhalb von VERSAND_A_1 durch eine Stored Procedure gesteuert werden (die folgenden Dateinamen würden als Parameter an die Stored Procedure übergeben):

CONNECT TO 'Adressen_A.gdb' AS ADR ...

CONNECT TO 'Post.gdb' AS POST ...

INSERT INTO Daten<br>
SELECT * FROM :ADR:Adressen<br>
WHERE ...

DISCONNECT ADR

<b>Der folgende Befehl soll dies mit Daten aus der Post-Datenbank verknüpfen:</b>

INSERT INTO Zaehler<br>
( Plz, Adr, Art )<br>
/* das Feld Art steuert die weitere Verarbeitung */<br>
SELECT d.plz, SUM(d.anzahl), p.art<br>
FROM Daten d<br>
JOIN :POST:PLZ p ON d.plz = p.plz<br>
GROUP BY d.plz

DISCONNECT POST

Aus dem Anwenderprogramm heraus läuft dies problemlos. (Das habe ich mit Local SQL auch schon realisiert.)

Unter Interbase ist es aber natürlich sinnvoll, die Daten vollständig auf dem Server zu behalten. Dort habe ich dies noch nicht probiert: Erst wenn ich Klarheit darüber habe, was zum Ziel führt, will ich es genauer konstruieren. Nach meinen bisherigen Kenntnissen aus den Beschreibungen habe ich starke Zweifel, ob es so funktioniert, und bitte um entsprechende Kommentierungen. Danke schön! Jürgen

[Thomas Steinmaurer]

Hallo Jürgen,
<br><br>
kurze Antwort: InterBase unterstützt keine Cross-Database-Queries. Weder in "purem" SQL noch in PSQL. Der einzige Weg, wenn Du Abfragen/Beziehungen zu Daten haben möchtest, muss das in einer Datenbank liegen.
<br><br>
Thoma

[Jürgen Thomas]

Danke für diese Antwort. Damit ist mir auch klar, warum ich bisher keine Aussage gefunden habe (zu einer Funktion, die nicht vorhanden ist, gibt es keine Hinweise).

Konsequenz daraus ist natürlich, dass ich auf separate Datenbanken VERSAND verzichte, sondern diese in die jeweilige ADRESSEN-Datenbank integriere.

Die <b>Verknüpfung</b> zwischen POST und VERSAND bzw. ADRESSEN muss ich also extern regeln. Mir schwebt dazu <b>folgendes Verfahren</b> vor:

* Eine separate DLL wird auf dem Datenbank-Server gespeichert.

* Von der eigentlichen Anwendung wird eine Prozedur in dieser DLL aufgerufen; diese bekommt als Parameter die Pfade der Datenbanken und benutzt ein eigenes Datenmodul mit Zugriff über Query auf die benötigten Datenbanken und Tabellen.

* Die Prozedur startet den ersten Teil der Ausführung über eine Stored Procedure in der ADRESSEN-Datenbank - darin ist u.a. enthalten:<br>
INSERT INTO Daten FROM Adressen<br>
- und wartet auf die Erledigung.

* Die Prozedur führt über Query den gewünschten Befehl aus:<br>
INSERT INTO Zaehler<br>
SELECT d.plz, SUM(d.anzahl), p.art<br>
FROM Daten d<br>
JOIN :POST:PLZ p ON d.plz = p.plz<br>
GROUP BY d.plz<br>
und verknüpft auf diesem Weg die Datenbanken.

* Die Prozedur startet die Fortsetzung der Ausführung in der ADRESSEN-Datenbank in einer weiteren Stored Procedure.

Zu diesem Verfahren hätte ich gerne <b>zusätzliche Tipps:</b>

* Funktioniert dies so, wie ich mir das vorstelle, oder gibt es bessere Lösungen?

* Habe ich recht, dass diese DLL-Prozedur besser auf dem Datenbank-Server liegt? Gibt es Standards, wo solche DLLs gespeichert werden sollten? Müssen sie dem Server bekannt gegeben werden? (Ich vermute nein, weil sie von der Anwendung aufgerufen wird, aber vielleicht übersehe ich einen Zusammenhang.)

* Das Datenmodul der DLL-Prozedur arbeitet sinnvollerweise mit 2 TIBDatabase-Komponenten. Welche der IBX-Komponenten passt in diesem Fall am besten für die Query?

* Auf welchem Weg kann die Stored Procedure des ersten Teils der Ausführung am besten der DLL-Prozedur mitteilen, dass sie fertig ist, (ich habe verstanden, dass es dazu mehrere Wege gibt, kann aber die Vor- und Nachteile noch nicht beurteilen) und dadurch die Fortsetzung veranlassen?

Für diese Erläuterungen herzlichen Dank! Jürge

[Bernd Wilske]

Hallo,

alle Daten, die zusammengehören, sollte mann auch in eine Datenbank legen. Alles andere sind Krücken.

Bernd Wilsk

[Jürgen Thomas]

Tut mir leid: Die Datenbank POST enthält Stammdaten für die Postleitzahlen; und die gelten einheitlich für alle ADRESSEN-Datenbanken. Also ist es nicht sinnvoll, diese Daten bei ADRESSEN zu speichern.

Ich brauche also ein Verfahren wie das von mir skizzierte. Jürge

[Jürgen Thomas]

Nachtrag: die Datenbank POST besteht aus 10 Tabellen mit etwa 400.000 Datensätzen; und nur etwa 1000 (unterschiedliche) Datensätze werden in ADRESSEN benötigt. Es dürfte einsichtig sein, dass diese Tabellen nichts in ADRESSEN zu suchen haben

[Frank Reim]

Hallo Jürgen,<BR><BR>
es ist nicht ganz klar, warum du die Daten unbedingt auf verschiedene Datenbanken aufteilen willst. In der Regel gibt es für eine Anwendung eine Datenbank. Und in dieser Datenbank erfolgt die Normalisierung durch die Trennung der Daten in sinnvollen Tabellen.<BR>
Bei der Zerstückelung in mehrere Datenbanken verzichtest du auf die meisten Vorteile einer SQL - Datenbank wie eben Stored Procedures, Fremdschlüssel, Join' s ...<BR>
In Paradox hattest du doch auch nur Tabellen...<BR>
<BR>Fran

[Andreas Kosch]

Hallo,

&gt;In der Regel gibt es für eine Anwendung eine Datenbank.

dies gilt aber nicht für alle Fälle. Auch ich hatte schon mit einer Anwendung zu tun, bei dem der Auftraggeber die Mitnutzung der bereits bestehenden "globalen" Kunden-Datenbank vorgeschrieben hatte. Wenn ein Auftraggeber in allen Bereichen (IT-Anwendungen) einen Überblick über die Kundenbeziehungen haben möchte, müssen alle Anwendungen (egal von wem und in was geschrieben) diese globale Kundendatenbank nutzen. Da es dort um MS SQL Server-Datenbanken ging, waren datenbankübergreifende SQL-Aufrufe auch kein Problem (dort dürfen die separaten Datenbanken sogar auf verschiedenen Servern liegen)

[Jürgen Thomas]

Danke für diese Kommentare; aber die Konzeption der Datenbanken ist zz. nicht mein Problem.

Zu dem Verfahren (siehe Diskussion und Kommentar #2) hätte ich gerne <b>zusätzliche Tipps:</b>

* Funktioniert dies so, wie ich mir das vorstelle, oder gibt es bessere Lösungen?

* Habe ich recht, dass diese DLL-Prozedur besser auf dem Datenbank-Server liegt? Gibt es Standards, wo solche DLLs gespeichert werden sollten? Müssen sie dem Server bekannt gegeben werden? (Ich vermute nein, weil sie von der Anwendung aufgerufen wird, aber vielleicht übersehe ich einen Zusammenhang.)

* Das Datenmodul der DLL-Prozedur arbeitet sinnvollerweise mit 2 TIBDatabase-Komponenten. Welche der IBX-Komponenten passt in diesem Fall am besten für die Query?

* Auf welchem Weg kann die Stored Procedure des ersten Teils der Ausführung am besten der DLL-Prozedur mitteilen, dass sie fertig ist, (ich habe verstanden, dass es dazu mehrere Wege gibt, kann aber die Vor- und Nachteile noch nicht beurteilen) und dadurch die Fortsetzung veranlassen?

Für diese Erläuterungen herzlichen Dank! Jürge

[Thomas Steinmaurer]

Hallo Jürgen,
<br><br>
die von Dir angeführte DB-übergreifende SQL-Anweisung wird so nicht funktionieren. Wo nun eine DLL liegt ist Geschmackssache. Für die Wartung und Einspielung neuer Versionen würde sich der Server anbieten, da man die DLL dann nur einmal ersetzen müsste. Ditto für die Anwendung (EXE).
<br><br>
Wie gesagt, der Knackpunkt an der ganzen Sache ist, dass InterBase keine DB-übergreifenden Dinge in einer SQL-Anweisung unterstützt. Mit der BDE als Zwischenschicht könnte es funktionieren, aber dazu holt sich die BDE <b>alle</b> Daten zum Client, um dann den Join auszuführen. Das kann eine erhebliche Performancebremse bedeuten.
<br><br>
Thoma