How to structure SP with many DML operations

Question

Hi
I have a stored procedure that does inserts, updates and deletes. My question is should this be within one begin and end or should each of these DML's have their own begin, end and exception blocks? What would be considered to be a good practice?

Answer 1

I'm with user553641 on this; keep things simple.
I write my programs as small, simple procedures or functions, that generally do one thing. I name them appropriately, and that helps things to be self documenting.
I group things together in a package, and there might be one or two main procedures that are exposed in the specification. Inside the package body, those main procedures will call the "sub" procedures (which in turn may call other procedures), etc.
Doing this has several benefits:
1. Testing becomes easier - you can test each bit of the code in isolation before running the code altogether - this is much, much easier than trying to test one massive "spaghetti" piece of code.
2. Easier maintenance - it's easy to see what the purpose of each procedure does, so if you need to make changes, you have a much better handle on what the potential impacts might be.
3. Easier to see what the flow of the program is when you're writing it - you can say "I want to promote someone" - so you have a main proc called "promote_person" which in turn calls two procedures: "change_job_title" and "alter_salary" - you don't have to consider the alter_salary part whilst you're working on the change_job_title part, etc (this is called "top down programming")
4. Promotes code reuse - "alter_salary" and "change_job_title" could be used elsewhere.
Think of it like building a house - would you build a house by taking one huge, house-sized brick and carve everything out, or would you use lots of small bricks to build up the walls bit by bit?