TQuery (TIBCQuery) - mehrere Master-Detailverbindungen komplett durchlaufen

[RonniS]

Hallo zusammen,

ich zerbreche mir seit Tagen darüber den Kopf und habe mich nun dazu entschieden, einmal hier im Forum nachzufragen.
Eigentlich bin ich mir auch nicht sicher, ob ich nun hier beim Thema Datenbanken oder eher beim Thema Algorithmen posten soll. Nun versuche
ich es einfach mal hier.

(Kurze evtl. weiterführende Information : Das ganze Konstrukt basiert auf einer FB-Datenbank, ich verwende Delphi XE2, und habe die Devart
TIBCQuerys im Einsatz.)

Es geht um folgendes Problem. Es sollen variabel verschiedene Tabellen mit einer Master-Detailverknüpfung miteinander verbunden werden und
aus jeder Tabelle sollen alle abhängigen Datensätze ausgelesen und anschließend als csv-Dateien exportiert werden..

Hier mal eine schematische Darstellung (wie gesagt, die Anzahl der Tabellen ist dynamisch und variabel) :

Tabelle 1
--- Tabelle 2
--- Tabelle 3
--- Tabelle 4
--- Tabelle 5
--- Tabelle 6

Tabelle 7
--- Tabelle 8
--- Tabelle 9
--- Tabelle 10

Tabelle 1 und Tabelle 7 sind jeweils die Mastertabellen, daran hängen in einer Master-Detailverknüpfung (1:n) jeweils die Tabellen, ähnlich wie die Skzizze zeigt..
Ein Beispiel .. (nur auf Tabelle 1,2,3 und 4 bezogen) :
Tabelle 1 enhält z.B. alle Belege , Tabelle 2 könnte z.B. die Belegpositionen enthalten (1 Beleg / 10 Positionen), Tabelle 3 wäre z.B. eine Artikeltabelle und Tabelle 4 wiederum könnte z.B. die Tabelle Kunden sein, die auch mit der Tabelle Beleg verknüpft ist.
Und nun ist die Herausforderung, alle Belege zu durchlaufen, dazu zu jedem Beleg alle Positionen, zu jeder Position alle Artikel (blödes Beispiel, weil das ja nur ein Artikel sein kann, aber ist ja auch nur ein Beispiel) und ebenfalls ein blödes Beispiel der Kunde, der an der Beleg hängt.
Dabei gilt, dass die Anzahl der Tabellen variabel sein kann..

Also es müsste nun so sein, dass

- erst der erste Datensatz von Tabelle 1,
- dann der erste Datensatz von Tabelle 2,
- dann alle Datesätze von Tabelle 3
- dann der zeite Datensatz von Tabelle 2,
- dann wieder alle Datensätze von Tabelle 3
....
- der zweite Datensatz von Tabelle 1
...

durchlaufen werden..

Vielleicht gibts aber auch noch nen ganz anderen Ansatz..

Nun ist es ja so, dass man von Tabelle 1 (TQuery) keinen Bezug auf Tabelle 2 (TQuery) erhält (also rein über das Objekt TQuery, TIBCQuery,.. ).. da gibts ja nix mit Clientsource oder so sondern nur von dem jeweils untergeordneten Objekt die Mastersource..
ist ja auch klar, weil es ja mehrere ClientSources geben kann. Wie durchläuft man die Tabellen am besten..
Ich dachte erst an eine rekursive Funktion, aber da man sich ja anhand der fehlenden ClientSource nicht von oben nach unten durchreihen kann, geht das wohl eher nicht..

Das kann doch eigentlich nicht so schwer sein, aber irgendwie hab ich mich da komplett verlaufen. :oops::cry:

Würde mich über jede Idee oder jeden Ansatz freuen.

Danke schon mal.

[lowmax_5]

...warum dieses nicht innerhalb einer FB-StoredProcedure realisieren:

Code:

for select Tabelle 1 do 
begin
for select Tabelle 2 do
begin
..
end
if I_TAB1='True' then
 for select Tabelle 3 do
 begin
 ..
 end

end

Das klappt prima ist schnellund die Businesslogik ist gleich in die DB ausgelagert...

[HeZa]

Hallo,

Zitat:

Tabelle 1 enhält z.B. alle Belege , Tabelle 2 könnte z.B. die Belegpositionen enthalten (1 Beleg / 10 Positionen), Tabelle 3 wäre z.B. eine Artikeltabelle und Tabelle 4
wiederum könnte z.B. die Tabelle Kunden sein, die auch mit der Tabelle Beleg verknüpft ist.

Um eine Lösung zu vorzuschlagen, muss du auch etwas zu den CSV-Dateien sagen.

Meinst du z.B. etwas wie folgendes:

2015-04-Belege.csv
2015-04-Positionen-Beleg-001.csv
2015-04-Positionen-Beleg-002.csv
...

oder so etwas:

2015-04-Belege.csv
2015-04-Positionen.csv
...

???

[Lemmy]

Zitat:

Also es müsste nun so sein, dass

- erst der erste Datensatz von Tabelle 1,
- dann der erste Datensatz von Tabelle 2,
- dann alle Datesätze von Tabelle 3
- dann der zeite Datensatz von Tabelle 2,
- dann wieder alle Datensätze von Tabelle 3
....
- der zweite Datensatz von Tabelle 1
...

durchlaufen werden..

dann bau dir das als ganz normale (Monster)SQL zusammen und lass es ausführen. WEnn dann alles in eine CSV Datei soll, brauchst Du eh alle Daten.

[RonniS]

Zitat:

Zitat von HeZa (Beitrag 1320115)

Hallo,

Zitat:

Tabelle 1 enhält z.B. alle Belege , Tabelle 2 könnte z.B. die Belegpositionen enthalten (1 Beleg / 10 Positionen), Tabelle 3 wäre z.B. eine Artikeltabelle und Tabelle 4
wiederum könnte z.B. die Tabelle Kunden sein, die auch mit der Tabelle Beleg verknüpft ist.

Um eine Lösung zu vorzuschlagen, muss du auch etwas zu den CSV-Dateien sagen.

Meinst du z.B. etwas wie folgendes:

2015-04-Belege.csv
2015-04-Positionen-Beleg-001.csv
2015-04-Positionen-Beleg-002.csv
...

oder so etwas:

2015-04-Belege.csv
2015-04-Positionen.csv
...

???

Ja Du hast recht, das habe ich bei meiner Geschichte gar nicht beschrieben. Die Ausgabe der csv-Dateien soll dann auch den Tabellen entsprechen, also so, wie
Du es im Beispiel 2 schon sehr treffend notiert hast :

2015-04-Belege.csv
2015-04-Positionen.csv
2015-04-Artikel.csv
2015-04-Kunden.csv

Also alle Datensätze einer Tabelle sollen auch in einer csv landen..

[RonniS]

Zitat:

Zitat von Lemmy (Beitrag 1320116)

Also es müsste nun so sein, dass

- erst der erste Datensatz von Tabelle 1,
- dann der erste Datensatz von Tabelle 2,
- dann alle Datesätze von Tabelle 3
- dann der zeite Datensatz von Tabelle 2,
- dann wieder alle Datensätze von Tabelle 3
....
- der zweite Datensatz von Tabelle 1
...

durchlaufen werden..

dann bau dir das als ganz normale (Monster)SQL zusammen und lass es ausführen. WEnn dann alles in eine CSV Datei soll, brauchst Du eh alle Daten.

Daran hatte ich auch schon gedacht, aber wie eben schon geschrieben, sollen die einzelnen Tabellen dann nicht in einer einzigen, sondern jeweils einzelnen
csv-Dateien ausgegeben werden :

2015-04-Belege.csv // Alle Belege
2015-04-Positionen.csv // Alle zugehörigen Positionen aller selektierten Belege
2015-04-Artikel.csv // Alle zugehörigen Artikel aller selektierten Positionen
2015-04-Kunden.csv // // Alle zugehörigen Kunden aller selektierten Belege

[RonniS]

Zitat:

Zitat von lowmax_5 (Beitrag 1320111)

...warum dieses nicht innerhalb einer FB-StoredProcedure realisieren:

Code:

for select Tabelle 1 do 
begin
for select Tabelle 2 do
begin
..
end
if I_TAB1='True' then
 for select Tabelle 3 do
 begin
 ..
 end

end

Das klappt prima ist schnellund die Businesslogik ist gleich in die DB ausgelagert...

Im Prinzip keine schlechte Idee, aber diese Lösung liefert mir ja auch "nur" alle Daten auf einen Rutsch und nicht getrennt.. leider..
ansonsten eine echt gute Idee, die Logik auszulagern.. vielleicht lässt die Idee dahinter doch irgendwie verwenden..

[Lemmy]

Zitat:

Zitat von RonniS (Beitrag 1320120)

Daran hatte ich auch schon gedacht, aber wie eben schon geschrieben, sollen die einzelnen Tabellen dann nicht in einer einzigen, sondern jeweils einzelnen
csv-Dateien ausgegeben werden :

2015-04-Belege.csv // Alle Belege
2015-04-Positionen.csv // Alle zugehörigen Positionen aller selektierten Belege
2015-04-Artikel.csv // Alle zugehörigen Artikel aller selektierten Positionen
2015-04-Kunden.csv // // Alle zugehörigen Kunden aller selektierten Belege

dann bau dir eine KLasse

Delphi-Quellcode:

TExportItem = class()
...

  property SQL: String;
  property FileName: String;

Dann stellst Du eine Collection von Items zusammen, jede bekommt ihre Individuelle SQL (und ist damit entsprechend anpassbar / optimiert. Die Collection übergibst du dann deinem CSV-Exporter und gut ist...

Die SQLs sollten ja nicht das Problem sein, oder?

Grüße

[HeZa]

Zitat:

Zitat von RonniS (Beitrag 1320119)

Ja Du hast recht, das habe ich bei meiner Geschichte gar nicht beschrieben. Die Ausgabe der csv-Dateien soll dann auch den Tabellen entsprechen, also so, wie
Du es im Beispiel 2 schon sehr treffend notiert hast :

2015-04-Belege.csv
2015-04-Positionen.csv
2015-04-Artikel.csv
2015-04-Kunden.csv

Also alle Datensätze einer Tabelle sollen auch in einer csv landen..

Das macht aus meiner Sicht die Sache einfacher. Du brauchst gar nicht mit Master Detail arbeiten, sondern baust Dir stattdessen pro Tabelle ein SQL.

Belege

Code:

SELECT b.* FROM belege b WHERE b.belegdatum >= '2015-04-01' AND b.belegdatum < '2015-05-01'

Positionen

Code:

SELECT p.* FROM 
  positionen p
WHERE
  p.belegid IN (SELECT b.belegid FROM belege b WHERE b.belegdatum >= '2015-04-01' AND b.belegdatum < '2015-05-01')

Kunden

Code:

SELECT k.* FROM
  kunden k
WHERE
  k.kundenid IN (SELECT b.kundenid FROM belege b WHERE b.belegdatum >= '2015-04-01' AND b.belegdatum < '2015-05-01')

[lowmax_5]

Zitat:

Im Prinzip keine schlechte Idee, aber diese Lösung liefert mir ja auch "nur" alle Daten auf einen Rutsch und nicht getrennt.. leider..
ansonsten eine echt gute Idee, die Logik auszulagern.. vielleicht lässt die Idee dahinter doch irgendwie verwenden..

Code:

if I_TAB1='True' then

Dieses liefert Dir bedingt die Abfrage, ob die Tabelle dabei ist.Wenn beim Input-Parameter 'True' übergeben wird, wedren die Daten abgefragt, ansonsten nicht. So lässt sich die Logik in der SP prima schalten. Und es ist vor allen Dingen SEHR schnell...

[RonniS]

Zitat:

Zitat von lowmax_5 (Beitrag 1320139)

Zitat:

Im Prinzip keine schlechte Idee, aber diese Lösung liefert mir ja auch "nur" alle Daten auf einen Rutsch und nicht getrennt.. leider..
ansonsten eine echt gute Idee, die Logik auszulagern.. vielleicht lässt die Idee dahinter doch irgendwie verwenden..

Code:

if I_TAB1='True' then

Dieses liefert Dir bedingt die Abfrage, ob die Tabelle dabei ist.Wenn beim Input-Parameter 'True' übergeben wird, wedren die Daten abgefragt, ansonsten nicht. So lässt sich die Logik in der SP prima schalten. Und es ist vor allen Dingen SEHR schnell...

Das mit dem

if I_TAB1='True' then

hab ich leider nicht so ganz verstanden. :oops: Wärst Du so nett und könntest mir das noch ein wenig genauer erklären? Danke Dir schon mal..

[lowmax_5]

Folgende Tabellen sind gegeben:

Code:

CREATE TABLE KUNDEN (
    KUNDENID  INTEGER,
    NAME      VARCHAR(10)
);

CREATE TABLE RECHNUNG (
    ID        INTEGER,
    KUNDENID  INTEGER,
    NR        VARCHAR(10),
    BETRAG    INTEGER
);

CREATE TABLE TABELLE3 (
    IDTAB3  INTEGER
);

Und folgende Stored Prodecure als Beispiel:

Code:

SET TERM ^ ;

CREATE OR ALTER PROCEDURE TEST_PROCEDURE (
    I_RECH INTEGER,
    I_TAB3 INTEGER)
RETURNS (
    O_KUNDENID INTEGER,
    O_NAME VARCHAR(10),
    O_ID INTEGER,
    O_NR VARCHAR(10),
    O_BETRAG INTEGER,
    O_PAR1 INTEGER,
    O_IDTAB3 INTEGER,
    O_PAR2 INTEGER)
AS
begin
for
 select KUNDENID,NAME from KUNDEN
 into :O_KUNDENID,:O_NAME
do
begin

    if (I_RECH=1) then
    for
     select ID, NR,BETRAG from RECHNUNG
     WHERE KUNDENID=:O_KUNDENID
     into :O_ID,:O_NR,:O_BETRAG
    do
    begin
     O_PAR1=100;
    end

    if (I_TAB3=1) then
    for
     select IDTAB3 FROM Tabelle3
     into :O_IDTAB3
    DO
    begin
     O_PAR2=200;
    end
end

end^

SET TERM ; ^

Du kannst nun mittels der Eingangsparameter 'I_RECH' und 'I_TAB3' die Datenmengen quasi dazuschalten.

I_RECH=1 : Rechnungdaten da AUFRUF:SELECT * FROM TEST_PROCEDURE(1, 0)
I_TAB3=1 : Daten aus Tabelle 3 da AUFRUF:SELECT * FROM TEST_PROCEDURE(0, 1)

Innerhalb der Stored Procedure kann so die Logik einfach verändert werden. Als Ausgabe gibt es immer eine entsprechende Tabelle.
Ich hoffe, dass cih es einigermassen erklären konnte...

[RonniS]

Vielen Dank lowmax und allen die hier gepostet haben, für Eure ausführlichen und detaillierten Informationen.

Ich habe von Euch viel Input und Anregungen erhalten und denke, dass ich so ziemlich von jedem von Euch was mit in die Entwicklung einfließen lassen kann.
Meine Idee ist nun, eine eigene Klasse, die dieses Konstrukt abbildet und möglicherweise eine Stored Procedure dynamisch generiert, je nach Tabellen und Abhängigkeiten.

In dieser Klasse kann ich sowohl Client- als auch Mastersources verwalten.

Vielen Dank nochmal.. :thumb: