Das Festschreiben innerhalb einer Schleife ist im Allgemeinen eine schlechte Idee (ebenso wie das automatische Festschreiben jedes Tools).
Das Festschreiben innerhalb einer Schleife macht es viel schwieriger, neu startbaren Code zu schreiben. Was passiert, wenn nach 3 Iterationen ein Fehler auftritt? Sie haben die Ergebnisse von 2 UPDATE jetzt erfolgreich festgeschrieben Aussagen. Vermutlich müssten Sie dann entweder herausfinden, welche Zeilen aktualisiert wurden, und Code schreiben, um die Aktualisierungen rückgängig zu machen, oder Sie müssten Code hinzufügen, der den Versuch vermeidet, die Daten für diese beiden erfolgreichen yearid zu aktualisieren Werte. Das ist durchaus möglich. Aber es beinhaltet das Schreiben einer Menge Code, um Ihren Fortschritt zu verfolgen, und macht Ihren Code im Allgemeinen viel komplexer.
Das Festschreiben innerhalb einer Schleife macht Ihren Code viel langsamer. Das Festschreiben ist im Allgemeinen eine ziemlich teure Operation. Es in einer Schleife zu tun, ist daher im Allgemeinen eine schlechte Idee. Es ist weniger ein Problem, wenn Sie nur ein paar Dutzend Schleifeniterationen haben. Aber wenn Sie Hunderte oder Tausende von Iterationen haben, können Sie am Ende leicht den Großteil Ihrer Zeit mit Festschreibungen verbringen.
Das Festschreiben innerhalb einer Schleife erhöht das Risiko, dass Sie einen ORA-01555-Fehler verursachen, erheblich. Ihre Abfrage gegen MyTable benötigt eine lesekonsistente Ansicht der Daten. Wenn Sie jedoch innerhalb der Schleife committen, teilen Sie Oracle mit, dass Ihre Sitzung kein älteres UNDO mehr benötigt Daten. Wenn Oracle UNDO löscht Daten, die Sie für eine nachfolgende Iteration der Schleife benötigen, erhalten Sie eine Fehlermeldung. Und dann haben Sie es wieder mit nicht neu startbarem Code zu tun, bei dem Sie erfolgreich N Iterationen durchlaufen haben, aber nicht wissen, welche Jahre verarbeitet wurden oder welche verarbeitet werden müssen.
Das Festschreiben innerhalb einer Schleife kann zu Datenkonsistenzproblemen führen. Wenn beispielsweise in einer anderen Sitzung Berichte ausgeführt werden, ist es für diese Berichte leicht, teilweise aktualisierte Daten zu sehen, was häufig bedeutet, dass die Daten inkonsistent sind. Wenn sich die Daten für 3 Jahre geändert haben, andere Jahre jedoch nicht, kann es sehr schwierig sein, die Berichte zu verstehen, und Personen (oder Prozesse) können leicht falsche Entscheidungen treffen.
Das Festschreiben innerhalb einer Schleife macht Ihren Code auch weniger wiederverwendbar. Wenn Ihr Code Commits (oder Rollbacks außer zu einem Sicherungspunkt, den Sie innerhalb des Blocks eingerichtet haben) enthält, kann er nicht von einem anderen Codeteil aufgerufen werden, dessen Transaktion noch nicht festgeschrieben werden soll. Das führt dazu, dass Leute versuchen, Ihre Logik ohne die Transaktionskontrolle neu zu implementieren oder die Transaktionsintegrität fälschlicherweise verletzen, was sie unweigerlich dazu führt, Anwendungen zu erstellen, die Probleme mit der Datenkonsistenz verursachen.
