Performance Probleme master-detail Datasets

[lxo]

Hallo,

folgende Problemstellung.
Ich hatte ein Formular mit 3 Querys und 3 Grids(cxGrids)

1. Kunden --> 2. Rezepturen --> 3. Rezepturartikel

Diese Tabellen sind miteinander verknüpft. (Master-Detail)
Mit prepared-Statements wurden die Detailtabellen aktualisert.
Performance war bis dahin ertragbar.

Jetzt kommen 2 weitere Querys hinzu.

1. Kunde --> 2.1. Rezepturen, 2.2. RezepturenSprache --> 3.1 Rezepturartikel, 3.1 RezepturartikelSprache


Also nun 3 Tabellen in Tabelle 2 und 3 jeweils 2 Gridviews.
Dadurch ist die Perfomance nun im Keller, die Maske ist kaum bedienbar.

Also auf ClientDataSets umgebaut.
Query - DataSetprovider - Clientdataset

Performance optimal beim bedienen.

Nun habe ich jedoch das Problem, das starten der Maske dauert knapp 5 Sekunden, vorher sofort da gewesen.
Problem ist das fetchen der Daten, da ich mir ja nun alle Daten hole.

Jemand noch eine Idee wie ich das am besten lösen könnte?

[mkinzler]

Wie sieht es mit Indizes aus?

[lxo]

Inwieweit Inidizes, seitens der Datenbanktabellen?

[mkinzler]

Ja. Sind solche für die Fremdschlüssel-Beziehungen vorhanden bzw. sind FK constraints angelegt (implizit werden dann auch die Indizes angelegt)?

[lxo]

Code:

select r.*
from MISCHKOPF r
left outer join MISCHKOPF_SPRACHE rs on rs.ID = r.LFDREZNR
left outer join DEKLKOPFFUSS dt on dt.DEKLID = r.DEKLTXT_ID
left outer join DEKLKOPFFUSS_SPRACHE dts on dts.ID = dt.DEKLID
left outer join SPRACHEN_SPRACHE ss on ss.SPRACHID = dt.sprachidaktiv

## MISCHKOPF ##
r.LFDREZNR = primary key
r.dekltxt_id = foreign key

## MISCHKOPF_SPRACHE ##
rs.ID = foreign key & primary key

## DEKLKOPFFUSS ##
dt.deklid = primary key
dt.sprachidaktiv = foreign key

## DEKLKOPFFUSS_SPRACHE ##
dts.id = foreign key & primary key

## SPRACHEN_SPRACHE ##
ss.sprachid primary key

so sieht der SQL im Grunde aus.

siehe unten IBExpert Sql-Analysis.

Der SQL an sich ist schnell, nur das fetchen dauert so lange (ca. 20.000 Datensätze).
Mir fällt nur auf das IB-Expert bei der Tabelle MISCHKOPF non-indexed-reads anzeigt aber ich verstehe nicht warum.

Code:

Plan
------------------------------------------------
PLAN JOIN (JOIN (JOIN (JOIN (R NATURAL,RS INDEX (RDB$PRIMARY503)),DT INDEX (RDB$PRIMARY579)),DTS INDEX (RDB$PRIMARY576)),SS INDEX (RDB$PRIMARY97))

Adapted Plan
------------------------------------------------
PLAN JOIN (JOIN (JOIN (JOIN (R NATURAL,RS INDEX (MISCHKOPF_SPRACHE_PKEY)),DT INDEX (DEKLKOPFFUSS_PKEY)),DTS INDEX (DEKLKOPFFUSS_SPRACHE_PKEY)),SS INDEX (SPRACHEN_SPRACHE_PKEY))

Query Time
------------------------------------------------
Prepare       : 31,00 ms
Execute       : 0,00 ms
Avg fetch time: 0,00 ms

Memory
------------------------------------------------
Current: 59.511.424
Max    : 60.633.704
Buffers: 3.000

Operations
------------------------------------------------
Read   : 0
Writes : 0
Fetches: 341
Marks  : 0


Enchanced Info:
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+----------+
|          Table Name           |  Records  |  Indexed  | Non-Indexed | Updates | Deletes | Inserts | Backouts |  Purges  | Expunges |
|                               |   Total   |   reads   |    reads    |         |         |         |          |          |          |
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+----------+
|SPRACHEN_SPRACHE               |         0 |        37 |           0 |       0 |       0 |       0 |        0 |        0 |        0 |
|MISCHKOPF_SPRACHE              |         0 |        14 |           0 |       0 |       0 |       0 |        0 |        0 |        0 |
|MISCHKOPF                      |         0 |         0 |          14 |       0 |       0 |       0 |        0 |        0 |        0 |
|DEKLKOPFFUSS_SPRACHE           |         0 |        13 |           0 |       0 |       0 |       0 |        0 |        0 |        0 |
|DEKLKOPFFUSS                   |         0 |        13 |           0 |       0 |       0 |       0 |        0 |        0 |        0 |
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+----------+

[mkinzler]

Warum outer join?

[jobo]

Zitat:

Zitat von lxo (Beitrag 1387613)

Inwieweit Inidizes, seitens der Datenbanktabellen?

Ja, bedeutet Deine Nachfrage, dass Dir die Bedeutung von Indizierung nicht geläufig ist?
Ich kann anhand Deiner Angaben nicht feststellen, ob Du minimal die Foreign Key Spalten indizierst.

Ich weiß auch nicht, ob es Sinn macht große / größere Datenmengen komplett auf den Client zu laden.
Was ist, wenn die nächste Query dazu kommt?

Ich würde bei klassischen Queries bleiben, statt Clientdataset und den Engpaß suchen. Fehlende Indizierung wäre mein Favorit.

Die Outer Joins halte ich für gerechtfertigt, sofern es Mengen gibt, die nicht gefüllt sein müssen.

Falls Du bei der Verdahtung der Submengen Fehler im Delphicode gemacht hast, die darauf hinauslaufen, dass eine Submenge geöffnet wird, ohne dass die gewünschte Einschränkung durch den Master feststeht, könnte das ähnliche Effekte haben. Der Effekt würde beim Debuggen sicher deutlich.

[hoika]

Hallo,

Zitat:

Problem ist das fetchen der Daten, da ich mir ja nun alle Daten hole.

Warum alle Daten?
Genau das musst du ändern.

Ich habe ein Kunden-Grid:
Select * From Kunde
(OK, alle Kunden holen, müsste aber auch nicht sein, man könnte eine Suche integrieren).

Wähle ich einen Kunden aus, zeigt mir das Programm die Rezepturen genau dieses einen Kunden an,
und zwar erst dann, wenn ich diesen Kunden wähle.

Womit hast Du denn deine Master-Detail-Sache aufgebaut, per Code oder in der IDE?

[p80286]

In diesem Falle wäre es ausreichend

SQL-Code:

 select Name,id from Kunden

auszuführen, diese Daten z.B. in einer Liste anzubieten und dann die Detaildaten über

SQL-Code:

select Name,Standort....
from Kunden join kundendetails...
where kunden.id=:id
...

zu holen.

Gruß
K-H

[Jasocul]

Klingt nach einem konzeptionellem Fehler.
Master-Details über die Delphi-Komponenten nutze ich nur, wenn ich zu faul und sicher bin, dass die Datenmengen klein genug sind und bleiben.

Indizes wurden ja schon angesprochen.
Wenn du ein Master-Detail-Konzept nachbilden willst, nutze z.B. im TDataSource des Masters das Ereignis OnDataChange. Dort aktualisierst du dann die Detail-Daten und hast dadurch das Master-Detail-Konzept nachgebildet.
Vorteil:
Geringe Datenmengen und höhere Performance bei richtigem Datenbank-Konzept (siehe z.B. Indizes).

[TigerLilly]

So wie hioka mache ich das auch:
Ich habe eine Basis-Liste, die anzeigt, welche Einträge es gibt. Das ist eine recht flotte SQL-Abfrage, die auch nicht bearbeitbar ist.
Von dieser Liste wählt der USer einen Datensatz aus, den er bearbeiten möchte + dann wird das Master/Detail Konstrukt befüllt, das sind dann aber nur mehr eine Handvoll Datensätze.

So eine Fülle an Daten abzurufen + via Netzwerk auf den Client zu laden ist ein rechtes Problem, denk mal an ein langsames WLAN, zB.

[lxo]

Danke für die ganzen Vorschläge und Tipps.

Ich habe den Ansatz mit den Datasets nun verworfen und werde versuchen das mit Queries zu lösen und die Datenmengen so gering wie möglich zu halten.