Pros and cons of using packages in Oracle

Question

I am fairly new to using packages. My team is deciding on whether or not to use packages in our applications. We have 4 applications that are using in-line sql currently. We are

Answer 1

If you're going to have different applications accessing the same tables, with the same business logic happening on the database (eg. constraints, etc), then stored procs are the way to go. Think of them as the interface between the "front end" (ie. anything that's not the database) and the database, in much the same way as a webservice provides an interface to the mid-tier (I think; I'm really not up on the non-db related architecture!).

Your publically callable stored procedures would be typically things like create_a_new_customer, add_a_new_address, retrieve_customer_details, etc, where the logic behind each action is coded and related procedures would be grouped into the same package. You wouldn't want to code a series of procedures that just do dml on the tables and expect the applications to work out when to call each procedure.

Answer 2

Just adding a side effect of using packages...

If I have a package with all the stored procedures and functions that is required for my application to run. Consider one small stored procedure suddenly fail due to some issue(eg. some alteration in table structure) or some other minor issue so that only one stored procedure becomes invalid.

In this case, will the entire package become invalid? Affecting the entire application?

On the other hand if do not use package and create standalone procs and functions, then only one proc will fail.

Answer 3

So you want to start a debate about the advantages versus the disadvantages of using a package? Ok, then I would leave the disadvantages part on you if you could share with us. I will just share with you tye advantages, not in my own words, since it would be a repetition of what Thomas Kyte already said here:

• break the dependency chain (no cascading invalidations when you install a new package body -- if you have procedures that call procedures -- compiling one will invalidate your database)

• support encapsulation -- I will be allowed to write MODULAR, easy to understand code -- rather then MONOLITHIC, non-understandable procedures

• increase my namespace measurably. package names have to be unique in a schema, but I can have many procedures across packages with the same name without colliding

• support overloading

• support session variables when you need them

• promote overall good coding techniques, stuff that lets you write code that is modular, understandable, logically grouped together....

If you are a programmer - you would see the benefits of packages over a proliferation of standalone procedures in a heartbeat.

Answer 4

Here's a handy decision diagram for this question.