Delphi-PRAXiS
Seite 1 von 2  1 2      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Performance Probleme master-detail Datasets (https://www.delphipraxis.net/194502-performance-probleme-master-detail-datasets.html)

lxo 30. Nov 2017 12:44

Datenbank: Interbase • Version: XE • Zugriff über: Delphi 10.1

Performance Probleme master-detail Datasets
 
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 30. Nov 2017 13:07

AW: Performance Probleme master-detail Datasets
 
Wie sieht es mit Indizes aus?

lxo 30. Nov 2017 14:51

AW: Performance Probleme master-detail Datasets
 
Inwieweit Inidizes, seitens der Datenbanktabellen?

mkinzler 30. Nov 2017 14:58

AW: Performance Probleme master-detail Datasets
 
Ja. Sind solche für die Fremdschlüssel-Beziehungen vorhanden bzw. sind FK constraints angelegt (implizit werden dann auch die Indizes angelegt)?

lxo 30. Nov 2017 15:18

AW: Performance Probleme master-detail Datasets
 
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 30. Nov 2017 15:38

AW: Performance Probleme master-detail Datasets
 
Warum outer join?

jobo 30. Nov 2017 22:36

AW: Performance Probleme master-detail Datasets
 
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 1. Dez 2017 06:37

AW: Performance Probleme master-detail Datasets
 
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 1. Dez 2017 07:23

AW: Performance Probleme master-detail Datasets
 
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 1. Dez 2017 07:47

AW: Performance Probleme master-detail Datasets
 
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).


Alle Zeitangaben in WEZ +1. Es ist jetzt 05:25 Uhr.
Seite 1 von 2  1 2      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz