Commit binnen een lus is over het algemeen een slecht idee (zo is het toestaan van een tool om automatisch te committen).
Committing binnen een lus maakt het veel moeilijker om herstartbare code te schrijven. Wat gebeurt er als je na 3 iteraties een fout tegenkomt? Je hebt nu met succes de resultaten van 2 UPDATE . vastgelegd verklaringen. Vermoedelijk moet u dan ofwel uitzoeken welke rijen zijn bijgewerkt en code schrijven om de updates ongedaan te maken, of u moet code toevoegen die voorkomt dat u probeert de gegevens voor die twee succesvolle yearid bij te werken. waarden. Dat is zeker mogelijk. Maar het vereist het schrijven van een heleboel code om je voortgang bij te houden en maakt je code over het algemeen veel complexer.
Als je binnen een lus commit, wordt je code veel langzamer. Vastleggen is over het algemeen een vrij dure operatie. Het is daarom over het algemeen een slecht idee om het in een lus te doen. Het is minder een probleem als je maar een paar dozijn loop-iteraties hebt. Maar als je honderden of duizenden iteraties hebt, kun je gemakkelijk het overgrote deel van je tijd besteden aan het vastleggen.
Committing binnen een lus verhoogt aanzienlijk het risico dat u een ORA-01555-fout veroorzaakt. Uw zoekopdracht tegen MyTable heeft een leesconsistente weergave van de gegevens nodig. Als je echter binnen de lus commit, vertel je Oracle dat je sessie niet langer ouder UNDO nodig heeft gegevens. Als Oracle UNDO opschoont gegevens die je nodig hebt voor een volgende iteratie van de lus, krijg je een foutmelding. En dan heb je weer te maken met niet-herstartbare code waarbij je met succes N-iteraties hebt doorlopen, maar je weet niet welke jaren zijn verwerkt of welke moeten worden verwerkt.
Committing binnen een lus kan problemen met de gegevensconsistentie veroorzaken. Als een andere sessie bijvoorbeeld rapporten uitvoert, kunnen die rapporten gemakkelijk gedeeltelijk bijgewerkte gegevens zien, wat vaak betekent dat de gegevens inconsistent zijn. Als de gegevens voor 3 jaar zijn veranderd, maar andere jaren niet, kan het erg moeilijk zijn om de rapporten te begrijpen en kunnen mensen (of processen) gemakkelijk verkeerde beslissingen nemen.
Door binnen een lus te committen, wordt uw code ook minder herbruikbaar. Als je code commits bevat (of rollbacks anders dan naar een savepoint dat je in het blok hebt ingesteld), kan het niet worden aangeroepen door een ander stuk code waarvan de transactie nog niet is vastgelegd. Dat leidt ertoe dat mensen proberen uw logica opnieuw te implementeren zonder de transactiecontrole of de transactie-integriteit onjuist schenden, wat er onvermijdelijk toe leidt dat ze applicaties bouwen die problemen met gegevensconsistentie introduceren.