October 15th, 2003, 02:45 AM
I have been told that the practice of using a single pl/sql package as a 'global' or 'common' area for storing variables and constants to be used by many program units in an application is bad, and that generally accepted good practice is to keep all program units discrete, passing all common data as parameters. The argument used is that it preserves the portability of the code. I am struggling to see this as outweighing the benefits of the package approach.
Does anyone have any insight or preferences to offer on the subject? I'd be grateful for a wider perspective on 'good practice' than from the handful of programmers here.
October 15th, 2003, 09:32 AM
ok, oracle guarantees that your SQL transactions are atomic, but it can be running two procedures at the same time. Yea, the transactions with the back end are still atomic. But you're saying you call some parent function from both? nono! The variables that you've set in there can be indiscriminately butchered by each and every child procedure! It depends on how these functions are used, by whom they are used, and what you see happening in the future. But not that much. If you want to have shared variables or something you need to utilize a locking mechanism either through files, pipes, blablabla semaphores, your own created semaphore file locking mechanism, whatever. Even if you're the only programmer running or using the functions, you are bound to step all over those globals at some point. For instance, probably the funnest and best use of PL/SQL is for web page authoring. There is never ever ever any instance where you can't just pass parameters around through the procedures. If two people have two different web pages open with the same parent function, and they set a global within a certain timeframe, they could crash another procedure, crash the parent, crash your whole server, blow up the whole building, you have no guarantees! parameters, good. globals, bad.