![]() |
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? |
AW: Performance Probleme master-detail Datasets
Wie sieht es mit Indizes aus?
|
AW: Performance Probleme master-detail Datasets
Inwieweit Inidizes, seitens der Datenbanktabellen?
|
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)?
|
AW: Performance Probleme master-detail Datasets
Code:
so sieht der SQL im Grunde aus.
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 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 | +-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+----------+ |
AW: Performance Probleme master-detail Datasets
Warum outer join?
|
AW: Performance Probleme master-detail Datasets
Zitat:
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. |
AW: Performance Probleme master-detail Datasets
Hallo,
Zitat:
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? |
AW: Performance Probleme master-detail Datasets
In diesem Falle wäre es ausreichend
SQL-Code:
auszuführen, diese Daten z.B. in einer Liste anzubieten und dann die Detaildaten über
select Name,id from Kunden
SQL-Code:
zu holen.
select Name,Standort....
from Kunden join kundendetails... where kunden.id=:id ... Gruß K-H |
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 22:26 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz