Who would have thought that just one year after the publication of Oracle PL/SQL Programming, a 916-page tome on "everything PL/SQL", I'd end up writing a second book about the PL/SQL language? Although back in September 1995 I wasn't arrogant enough to think that I knew all there was to know about PL/SQL, I also underestimated how much more I had still to learn!
I am firmly of the belief that one never stops learning -- as long as one is open to learning. The area of PL/SQL in which I needed lots more education turned out to be packages. In my first book I explained how to build and use packages. I even provided lots of examples of package construction. But I started to realize that this wasn't enough. Over the past year, I have been designing and developing a set of packages to help me build PL/SQL-based applications. This was a thoroughly selfish effort: I wanted to be as productive as possible, and I wanted to overcome a number of weaknesses -- however transient -- in the PL/SQL language. In the process of writing this software, I learned a good deal about the best ways to build PL/SQL code, especially regarding packages. I also discovered some very interesting techniques that can make packaged software more maintainable, accessible, and easy to use.
As my thinking on the construction of packages crystallized, I began to view all of my packages as a library of code that could be used by any PL/SQL developer. I also realized that I wanted to share the new techniques and lessons I had uncovered. The result? This book and the PL/Vision product.
How often do you find yourself writing a program and simultaneously thinking: somebody must have done this before! You feel certain that you are reinventing the wheel. Worse, if you are sufficiently honest with yourself, you will also admit that someone else has probably spent more time on the problem and has already come up with a better solution than you are likely to develop for your specific application.
Often, you know you should take the time to "genericize" a program so that you can use it again and again in different circumstances. Somehow, however, you never find the time -- and the mental space -- to take your code to that higher level of abstraction.
So you limp along, accepting a relatively low level of productivity and reusing a truly minimal amount of code. You write the same things over and over and simply push aside the feeling that you are wasting your time.
Oracle developers are fortunate to be able to use an advanced, robust language like PL/SQL. PL/SQL developers are, on the other hand, less than fortunate (at least as of September 1996) to find that the supporting environment for PL/SQL is still very immature. Where are the debuggers, the code formatters and generators, the toolboxes of reusable programs and objects? When will we have a powerful editor that knows about PL/SQL syntax and -- more importantly -- the stored code available for execution?
When, you might also ask, will this guy stop complaining? It is acceptable to identify weaknesses. It is constructive to analyze areas for improvement. At some point, however, you have to stop whining and start improving things for yourself. Best yet, keep on whining but engage in self-improvement at the same time!
This book will help you write better packages. It will also show you how to use the "prebuilt" packages of the PL/Vision software product -- my attempt to change the "situation on the ground" for PL/SQL programmers. Finally, I hope that it will, via examination of my source code and the way I separated functional areas in PL/Vision, offer a blueprint for PL/SQL developers to discover how to take full advantage of PL/SQL packages in their day-to-day programming.
Why did I write this book? I have the following modest objectives:
Make sure as many PL/SQL developers as possible know about packages and how to use them. Students who attend my training sessions soon come to realize after a day or two that the answer to almost any question I ask is: "Build a package." They also often stumble out of the sessions chanting the mantra: "Packages, packages, packages..." I wrote this book and the companion software because I believe that packages are the single most important element of the PL/SQL language. You can never go wrong putting your code inside a package. You will, on the other hand, almost always regret not placing your functions and procedures inside packages from the get-go.
Get my software into the hands of as many PL/SQL developers as possible. I like to see others get the benefit of my efforts. I like the idea that my prebuilt software will free up your time. This book contains a full-use version of the PL/Vision product, PL/Vision Lite, along with extensive documentation on how to use this library.
Of course, I also like to be compensated for my efforts, so you can also purchase a license to PL/Vision Professional; see the RevealNet website at >http://www.revealnet.com">
(Unless otherwise noted, all references in this book to PL/Vision are to PL/Vision Lite.) You might use just a little bit of PL/Vision; you might leverage every single package into your production applications. Many readers will do nothing more than cannibalize PL/Vision, learning from these packages how to improve their own code. All of these variations are welcome and encouraged!
Make my readers more creative and effective problem solvers. I've had a wonderful time thinking about how to modularize and construct in layers basic packages to improve PL/SQL programming. I learned about effective ways to construct packages and about all kinds of magic you can do when you internalize the features and benefits of packages stored in shared memory. When I encountered an obstacle, I didn't throw up my hands and look for a workaround. Instead, I asked myself: "What kind of package can I build to solve this problem?" That attitude forced me to be creative, and there is nothing more exciting than unleashed creativity. I hope that this book and the software that comes with it inspires every one of my readers to fashion new answers to old questions and newer answers to new questions. You will never regret the conceptual leaps you take in the process.
Copyright (c) 2000 O'Reilly & Associates. All rights reserved.