Ok, ich will das hier nicht sprengen, in SQLite ist es vielleicht irgendwie anders.
Ich würde sagen, Du wirst keinen Oracle Mitarbeiter finden, der behauptet, mach kleine Transaktionen, weil es dann schneller ist. Und ein Redolog muss so groß sein, dass alle Transaktionen, die die Businesslogik fordert auch durchgezogen werden können. (Natürlich kann man Operationen definieren, die ein -immer nur endlich großes- Redolog sprengen).
Und richtig, Transaktionen sorgen für die Möglichkeit eines vollständigen Rollback.
Welchen Sinn macht es dann, logisch zusammenhängende Oprationen in mehrere kleine Transaktionen zu zerlegen, so dass im Fall eines Rollbacks ein inkonsistenter Zustand zurückbleibt?
In keinem meiner Programme gibt es irgendeine Codezeile, die sich damit auseinandersetzt, wie weit eine Operation bereits fortgeschritten ist, was auf den Schrott kommt, geschweige denn vielleicht kommen müsste. Dafür ist die
DB mit ihren Transaktionen zuständig.
Na vielleicht etwas übertrieben, wenn Millionen von Datensätzen importiert werden müssen, kann man eine Entwickler
DB schon etwas schonen und stückeln, aber es ist m.E. prinzipiell falsch.
Wenn eine große Transaktion in einem Produktivsystem andere Benutzer behindert und das häufig der Fall ist, ist das System unterdimensioniert, falsch administriert oder falsch konzipiert.