Misc Basic PL/SQL Application Design/Programming Questions 101 (101.1)

Question

---****** background for all these questions is at bottom of this post:
Question 1:
I read a little on the in and out parameters and that IN is "by reference" and OUT and IN-OUT are by value. To me "by reference" means "pointer" as in C programming. So it seems to me that I could call a function with an IN parameter and NOT put it on the right side of an assignment statement. In other words, I'm calling my function
get_something(IN p_test1 varchar2) return varchar2;
from SP1 which has a variable named V_TEST1.
So.... can I do this? (method A):
get_something(V_TEST1);
or do I have to do this (method B):
V_TEST1 := get_something(V_TEST1);
Also, although this may muddy the thread (we'll see), it seems to me that IN, since its by reference, will always be more efficient. I will have many concurrent users using this program: should this affect my thinking on the above question?
-- ******* background *******
So Far:<< I've read and am reading all over the net, read and reading oracle books from oracle (have a full safari account), reading Feurstein's tome, have read the faq's here.
Situation Bottom Line:<< Have an enormous amount to do in a very little time. Lots riding on this. Any and all pointers will be appreciated. After we get to some undetermined point I can re-do this venture as a pl/sql faq and submit it for posting (y'alls call). Some questions may be hare brained just because I'm freaking out a little bit.
Situation (Long Version):<< Writing a pl/sql backend to MS Reporting Services front end. Just started doing pl/sql about 2 months ago. Took me forever to find out about ref-cursor as the pipe between oracle and all client applications. I have now created a package. I've been programming for 20 years in many languages, but brand new to pl/sql. However, pl/sql sql has freed me from myriad of limitations in MS RS's. My program is starting to get big (for me -- I do a lot in a little) pks is currently 900 lines with 15 functions so far. Currently SP (pls) is back up to 800 lines. I get stuff working in the sp then turn it into a function and move it to the package.
What does application do?:<<<< Back End for MS Reporting Services Web front end. It will be a very controlled "ad-hoc" (or the illusion of ad-hoc) web interface. All sql queries are built at run-time and executed via "open ref cusor for -- sql statement -- end;" data returned via OUT ref_cursor. Goal is to have almost 100% of functionality in a package. Calling SP will be minimalist. Reporting Services calls the SP, passes X number of parameters, and gets the ref_cursor back.
Oracle Version: 10.2 (moving to 11g in the next 3 months).Environment: Huge DW in a massively shared environment. Everything is locked down and requires a formal request. I had to have my authenticated for a couple dbms system packages just to starting simple pl/sql programs.

Answer 1

Brad Bueche wrote:
Question 1:
I read a little on the in and out parameters and that IN is "by reference" and OUT and IN-OUT are by value. To me "by reference" means "pointer" as in C programming. So it seems to me that I could call a function with an IN parameter and NOT put it on the right side of an assignment statement. The IN parameter is not passing by reference. It is passing by value. This means variable/value of the caller used as parameter, is copied to the (pushed) stack of code unit called.
An OUT parameter means that the value is copied from the called unit's stack to the caller (and the current value of the caller's variable is overwritten).
To pass by reference, the NOCOPY clause need to be used. Note that is not an explicit compile instruction. The PL/SQL engine could very well decide to pass by value and not reference instead (depending on the data type used).
Note that the ref cursor data type and the LOB data types are already pointers. In which case these are not passed reference as they are already references.
The NOCOPY clause only make sense for large varchar2 variables (these can be up to 32KB in PL/SQL) and for collection/array data type variables.
As for optimising PL/SQL code - there are a number of approaches (and not just passing by reference). Deterministic functions can be defined. PL/SQL code can be written (as pipelined tables) to run in parallel using the default Oracle Parallel Query feature. PL/SQL can be manually parallelised. Context switches to the SQL engine can be minimised using bulk processing. Etc.
Much of the performance will however come down to 2 basic issues. How well the data structures being processed are designed. How well the code itself is modularised and written.