Funktionsweise DBTransaktionen

[jobo]

Zitat von hoika:

Hm, eigener Thread ?

Ich habe 10 SPs, die je nach Konfiguration nacheinander aufgerufen werden müssen in einer einzigen Transaktion.
SP1->SP2->SP3->SP6->SP10
oder
SP1->SP3->SP9->SP6
oder
SP10->SP8->SP6
oder oder oder

Und jetzt bei mal pro möglicher Konfiguration eine SP, viel Spass.
Waren das 10! (Fakultät) Möglichkeiten?

Na gut!

Also ich sehe da kein Problem. Wir machen sowas. Z.B. in Oracle* ca. 20 generische "Packages" (Oracle Package grob = ~Sammlung von SP) mit geschätzt jeweilse 10-50 SP und das ganze nochmal größer für die Business Logik des Kunden.

Und weg von den SP, einfach mit AB:
aus Delphi Code

Code:

[dbcompo.beginTransaction]
SP1->SP3->SP9->SP6
SP10->SP8->SP6
[dbcompo.endTransaction]

wird ein ExecSQL mit .sql=

Code:

execute block
as
begin
SP1->SP3->SP9->SP6
SP10->SP8->SP6
end

plus try except

Das ist im Sinne von Codeaufwand mehr oder weniger identisch. Auch wenn die Rangehensweise anders ist und man es nicht 1:1 umstellen kann. Man hat mit AB absolute Flexibilität und kann SP und einzlene Statements mischen, wie benötigt.
SP daraus zu machen, ist m.E. eher eine "Hygiene"frage oder wie man das auch nennen mag. Das ist dann neben einigen praktischen Aspekten etwas, was wirklich keine Ressourcenvorteile o.ä. bringt, also weit mehr Geschmackssache.

*analog in Postgres (ohne packages),
oder eben auch in firebird möglich,
und seit 8 auch in mysql

[hoika]

Hallo,
SP hatte ich ketzerisch genommen

Wir benutzen if then auf der Client-Seite.

Delphi-Quellcode:

DB.StartTransaction;
Proc1;
if Bla then
begin
  Proc2;
  Proc4;
end;
DB.Commit;

Bei Firebird spielt es schon eine Rolle, ob die DB bei jedem SQL-Befehl eine automatische Transaktion startet oder wir das per Client machen. Das hat mit der MGA (multi generation architecture) zu tun.
Es gibt aktive Transaktionen, die FB berücksichtigen muss.
Je mehr offen sind, desto mehr muss die DB sich quälen.

Deshalb auch immer der Hinweis, keine lange laufenden Transaktionen benutzen ala:
- Fenster öffnen (nein, mache wieder zu! -> ist kalt, ein Delphi-Fenster meinte ich )
- Transaktion starten
- auf Nutzer-Eingabe warten
- 30 Minuten Pause, Mittag
- Insert/Update
- Commit

Machen das 2 Nutzer und 20 andere hämmern fleißig weiter Daten ein, bleibt diese eine Transaktion offen.

[jobo]

Also genau das meine ich ja, unabhängig von der FB Architektur. Je mehr und je länger Transaktionen offen sind, desto anstrengender und blockierender für die DB. Wahrscheinlich ist die Kurve 'offene Transaktionen gegen Gesamtlast' irgendwie logarithmisch, jedenfalls nicht linear.

Da kann FB jedenfalls nichts für.

Wenn man es schafft (sich die Mühe macht), andauernde Transaktionen in eine SP oder einen Anoymen Block zu packen, der dann gar nicht anders kann, als dann allein auf der DB zu laufen, hat man (der armen) DB eine Menge erspart.

Bei vielen Systemen ist es vielleicht egal, weil sie nie eine kritische Größe erreichen. Ich habe auch keine realistischen Vergleichswerte, aber ich denke, man kann die Leistungsfähigkeit einer DB damit stark erweitern, mehr als verdoppeln sagen wir mal. Und das (eine reine Verdoppelung) wäre im Rahmen von Hardware Erweiterungen schon ein großer Kostenfaktor (leider nicht linear).

[hoika]

Hallo,
hm, eine SSD statt einer HDD einzubauen, sorgt zumindestens bei Firebird für ordentlich Dampf,
ohne eine Zeile programmiert zu haben

[p80286]

Naja,
Speicher ist durch nichts zu ersetzen, es sei denn durch noch mehr Speicher,

Gruß
K-H

[jobo]

Zitat von hoika:

Hallo,
hm, eine SSD statt einer HDD einzubauen, sorgt zumindestens bei Firebird für ordentlich Dampf,
ohne eine Zeile programmiert zu haben

Genau! Und wenn schon SDD drin ist, bau ich doppelt soviel SSD ein, genial!

Notfalls kann man sich ja bald auch flotte Quantencpuzeit in der IBM Cloud mieten.