Re: PHP 7.xx: fbclient.dll bzw. gds32.dll wird nicht installiert.
Verfasst: Mo 3. Jun 2019, 12:14
Andere DB's mögen die Anzahl Sätze daher kennen, dass sie die Daten grundsätzlich erst intern in eine Arbeitstabelle kopiert bevor sie zurückgegeben wird.
Dies funktioniert auch i.d.R. nur bei statischen Cursor'n.
Bei dynamischen Cursorn kann sich die Datenbasis während der Abfrage noch ändern.
Manchmal ist der Wert aber auch nur eine Abschätzung der zu erwartenden Daten, je nach Implementation.
Da die Firebird die Daten aber bereits beim Lesen zur Verfügung stellt, ist die Anzahl der Datensätze vorher nicht zu ermitteln.
So etwas zu realisieren würde eine drastische Performanceeinbuße mit sich bringen, da dann tatsächlich erst alles ermittelt werden müsste, bevor die erste Datenzeile zurückgegeben werden kann.
Auf Grund der möglichen sehr komplexen Abfragetechnik, [rekursive] CTE's, union/left/right/inner Joins, derived tables usw., ist dies sehr aufwändig.
Hinzu käme ebenso der z.T. enorme Platzbedarf für die temporäre Kopie der Daten.
Jede Abfrage, die Indizes verwenden kann und somit keine temporären Daten benötigt, ist da immer vorzuziehen.
Wer unbedingt die Anzahl Sätze vorher benötigt, kann auch einen
Select count(*) from
(<Ursprungsselect>) x
durchführen. Er darf sich dann aber nicht über Performancenachteile wundern. Auch Abfragen von unter 100ms verdoppeln sich dadurch in der Queryzeit.
Zu berücksichtigen ist auch noch, dass durch das Versioning, dynamische Cursor ausgeschlossen sind, da Transaktionen nun mal das gleichzeitige Lesen von veränderten Daten durch aktive andere Transaktionen verhindert.
Beim Einsatz von Autocommit, kann also auch eine Count(*) gefolgt von der nächsten Abfrage durchaus ein anderes Ergebnis bringen, es sei denn ich arbeite sowieso alleine mit der Datenbank und verwende keine parallelen Verbindungen.
Dies funktioniert auch i.d.R. nur bei statischen Cursor'n.
Bei dynamischen Cursorn kann sich die Datenbasis während der Abfrage noch ändern.
Manchmal ist der Wert aber auch nur eine Abschätzung der zu erwartenden Daten, je nach Implementation.
Da die Firebird die Daten aber bereits beim Lesen zur Verfügung stellt, ist die Anzahl der Datensätze vorher nicht zu ermitteln.
So etwas zu realisieren würde eine drastische Performanceeinbuße mit sich bringen, da dann tatsächlich erst alles ermittelt werden müsste, bevor die erste Datenzeile zurückgegeben werden kann.
Auf Grund der möglichen sehr komplexen Abfragetechnik, [rekursive] CTE's, union/left/right/inner Joins, derived tables usw., ist dies sehr aufwändig.
Hinzu käme ebenso der z.T. enorme Platzbedarf für die temporäre Kopie der Daten.
Jede Abfrage, die Indizes verwenden kann und somit keine temporären Daten benötigt, ist da immer vorzuziehen.
Wer unbedingt die Anzahl Sätze vorher benötigt, kann auch einen
Select count(*) from
(<Ursprungsselect>) x
durchführen. Er darf sich dann aber nicht über Performancenachteile wundern. Auch Abfragen von unter 100ms verdoppeln sich dadurch in der Queryzeit.
Zu berücksichtigen ist auch noch, dass durch das Versioning, dynamische Cursor ausgeschlossen sind, da Transaktionen nun mal das gleichzeitige Lesen von veränderten Daten durch aktive andere Transaktionen verhindert.
Beim Einsatz von Autocommit, kann also auch eine Count(*) gefolgt von der nächsten Abfrage durchaus ein anderes Ergebnis bringen, es sei denn ich arbeite sowieso alleine mit der Datenbank und verwende keine parallelen Verbindungen.