Hi,
Zitat von
Robert_G:
Hast du dir das genau überlegt?
Wenn ich ein SELECT an den Server schicke, bekomme ich nur die Ergebnissse zurück, nicht mehr.
Klar, die SP von Hansa ist jetzt nicht wirklich der Brüller, so dass dort eine Begrenzung der Datenmenge nicht stattfindet, da SUM schon eine eingebaute Funktion ist. Sobald er aber die Ergebnismenge wieder in eine andere Tabelle zurückschreiben will (z.B. Logbuch), dann spart er sich mit dem Einsatz einer entsprechenden SP den Datentransfer!
Zitat von
Robert_G:
Wenn sich das Statement zwischen zwei Aufrufen nicht ändert (solange sie zeitlich nicht zu weit auseinander liegen), muss es nicht neu geparst werden, in Oracle wird es auch kein 2. Mal komplett ausgeführt, es werden nur die Werte im Cache neu gefiltert.
Das mag in Oracle sein, bei
IB/
FB kann ich mir dieses Verhalten gerade nicht vorstellen. Ich gehe davon aus, dass bei jedem
SQL-Statement der komplette Ablauf durchgegangen wird.
Zitat von
Robert_G:
Das Ganze setzt natürlich voraus, dass
IB/
FB über einen vernünftigen Optimizer verfügt, der den
Query-Plan erstellt und einem entsprechenden Cache-System. (ich habe keinen Plan von
IB/
FB 
)
1 ja, 2 ja, 3 nein
Zitat von
Robert_G:
Wenn Hansa die Daten nur in dieser Form haben will, wäre eine SP sinnlos & langsamer.
Will er noch mehr mit den Daten anstellen, bevor er sie im Client benutzt, wäre natürliche eine SP angebracht.
Wie schon gesagt auf keinen Fall langsamer, da sich
IB/
FB einige Schritte beim Ausführen einer SP spart. Aber, selbst wenn eine SP langsamer wäre würde ich diese einem normalen
SQL-Statement vorziehen, da sie sich wesentlich leichter ändern lässt als das Client-Programm, vorallem wenn es sich beim Kunden befindet!
Grüße
Lemmy