«Term Fly Presents Oracle PL/SQL Best Practices By Steven Feuerstein Publisher : O'Reilly Pub Date : April 2001 ISBN : ...»
Term Fly Presents http://www.flyheart.com
Oracle PL/SQL Best Practices
By Steven Feuerstein
Publisher : O'Reilly
Pub Date : April 2001
ISBN : 0-596-00121-5
Pages : 202
Oracle PL/SQL Best Practices is a concise, easy-to-use summary of best
practices in the program development process. It covers coding style, writing SQL in PL/SQL, data structures, control structures, exception handling, program and package construction, and built-in packages.
Complementary code examples are available on the O'Reilly web site.
Includes a pull-out quick-reference card.
Preface When I first started writing about the Oracle PL/SQL language back in 1994, the only sources of information were the product documentation (such as it was) and the occasional paper and presentation at Oracle User Group events. Today, there are at least a dozen books that focus exclusively on PL/SQL, numerous products that help you write PL/SQL code (integrated development environments, knowledge bases, etc.), training classes, and web sites. And the community of PL/SQL developers continues to grow in size and maturity, even with the advent of Java.
Access to information about PL/SQL is no longer the challenge. It can, on the other hand, be difficult to make sense of all the new features, the numerous resources, the choices for tools, and so on. When it comes to writing a program or an entire application, developers have, over and over again, expressed the desire for advice.
• How should I format my code?
• What naming conventions, if any, should I use?
• How can I write my packages so that they can be more easily maintained?
• What is the best way to query information from the database?
• How can I get all the developers on my team to handle errors the same way?
So many questions, so much burning desire to write code well, and so few resources available to help us do that.
So I decided to write a book that offers a concentrated set of "best practices" for the Oracle PL/SQL language. The objective of this book is to provide concrete, immediately applicable, quickly located advice that will assist you in writing code that is readable, maintainable, and efficient.
You will undoubtedly find recommendations in this book that also appear in some of my other books; I hope you will not be offended by this repetition. It's simply impossible to offer in a single book everything that can and should be written about the Oracle PL/SQL language. While I plan to reinforce these best practices in the appropriate places in my other texts, I believe that we will all benefit from also having them available in one concise book, a book designed, beginning to end, to give you quick access to my recommendations for excellent PL/SQL coding techniques.
Structure of This Book Oracle PL /SQL Best Practices is composed of nine chapters and one appendix. Each chapter contains a set of best practices for a particular area of functionality in the PL/SQL language. For each best practice, I've provided as many of the following
elements as are applicable:
A single sentence that describes the best practice and provides an identifier for it in the form XXX-nn (where XXX is the type of best practice—for example, EXC for exception handling—and nn is the sequential number within this set of best practices); see Section P.4 for how to use this identifier online. I have, whenever possible, sought to make this title stand on its own. In other words, you should be able to glance at it and understand its impact on how you write code. This way, after you've read the entire best practice, you can use Appendix A to instantly remind you of best practices as you write your code.
Description A lengthier explanation of the best practice. It's simply not possible to cover all the nuances in a single sentence!
Example We learn best from examples, so just about every best practice illustrates, through code and/or anecdote, the value of the best practice. Whenever it makes sense, I put the example code in a file that you can use (or learn from) in your own programming environment. You'll find these files on the O'Reilly web site (see Section P.4 later in this Preface).
Benefits Why should you bother with this best practice? How crucial is it for you to follow this particular recommendation? This section offers a quick review of the main benefits you will see by following the best practice.
Wouldn't it be great if we lived in a world in which following a best practice was all-around easier than the "quick and dirty" approach? That is, unfortunately, not always the case. This element warns you about the challenges, or drawbacks, you might face as you implement the best practice.
Resources In the world of the Internet, everything is connected; no programmer stands alone! This section recommends resources, ranging from books to URLs to files containing code, that you can use to help you successfully follow this best practice. Where filenames are shown in this section, they refer to files available on, or referenced by, the O'Reilly web site.
Here are brief descriptions of the chapters and appendix:
Chapter 1 steps back from specific programming recommendations. It offers advice about how to improve the overall process by which you write code.
Chapter 2 offers a series of suggestions on how to format and organize your code so that it is more readable and, therefore, more maintainable.
Chapter 3 takes a close look at how you ought to declare and manage data within your PL/SQL programs.
Chapter 4 is a "back to basics" chapter that talks about the best way to write IF statements, loops, and even the GOTO statement! Sure, these aren't terribly complicated constructs, but there are still right and wrong ways to work with them.
Chapter 5 covers another critical aspect of robust application development: exception handling, or what to do when things go wrong.
Chapter 6 focuses on the most crucial aspect of PL/SQL development: how you should write the SQL statements in your programs.
Chapter 7 offers advice on how best to build your procedures, functions, and triggers—the program units that contain your business logic. It also includes best practices for parameter construction.
Chapter 8 steps back from individual program units to present recommendations for packages, the building blocks of any well-designed PL/SQL-based application.
Chapter 9 focuses on how to take best advantage of a few of the most often used of the packages provided to us by Oracle Corporation.
Appendix A compiles the best practice titles across all the chapters into a concise resource. Once you have studied the individual best practices, you can use this appendix as a checklist, to be reviewed before you begin coding a new program or application.
How to Use This Book My primary goal in writing this book was to create a resource that would make a concrete, noticeable difference in the quality of the PL/SQL code you write. To accomplish this, the book needs to be useful and usable not just for general study, but also for day-to-day, program-to-program tasks. It also needs to be concise and to the point. A 1,000-page text on best practices would be overwhelming, intimidating, and hard to use.
The result is this relatively brief (I consider any publication under 200 pages a major personal accomplishment!), highly structured book. I recommend that you approach
Oracle PL/SQL Best Practices as follows:
1. Read Section P.3. Some of the best practices in this book—whole chapters, in fact—will have a much higher impact than others on the quality and efficiency of your code. If you find that your current practices (or those of your organization) are far from the mark, then you will have identified your priorities for initial study.
2. Skip to Appendix A and peruse the best practice titles from each chapter. If you have been programming for any length of time, you will probably find yourself thinking: "Yes, I do that," and "Uh-huh, we've got that one covered."
Great! I would still encourage you to read what I've got to say on those topics, as you might be able to deepen your knowledge or learn new techniques. In any case, a quick review of the appendix will allow you to identify areas that are new to you, or perhaps strike a chord, as in "Oh my gosh, that program I wrote last week does exactly what Steven says to avoid. Better check that out!"
3. Dive into individual chapters or best practices within chapters. Read a best practice, wrestle with it, if necessary, to make sure that you really, truly agree with it. And then apply that best practice. This isn't an academic exercise. You will only truly absorb the lesson if you apply it to your code—if you have a problem or program that can be improved by the best practice.
If you are new to programming or new to PL/SQL, you will certainly also benefit greatly from a cover-to-cover reading of the text. In this case, don't try to fully absorb and test out every best practice. Instead, read and think about the best practices without the pressure of applying each one. When you are done, try to
picture the best practices as a whole, reinforcing the following themes:
• I want to write code that I—and others—can easily understand and change as needed.
• The world is terribly complex, so I should strive to keep my code simple. I can then meet that complexity through carefully designed interaction between elements of my code.
Then you will be ready to go back to individual chapters and deepen your understanding of individual best practices.
The other crucial way to take advantage of this book is to use the code provided on the companion web site. See Section P.4 for detailed information on the software that will help you bring your best practices to life.
Not All Best Practices Are Created Equal
This book contains about 120 distinct recommendations. I could have included many, many more. In fact, I filled up a Rejects document as I wrote the book. Following the proven, "top-down" approach, I first came up with a list of best practices in each area of the language. Then I went through each area, filling in the descriptions, examples, and so on. As I did this, I encountered numerous "best practices" that surely were the right way to do things. The reality, however, is that few people would ever bother to remember and follow them, and if they did bother, it would not make a significant difference in their code.
I had realized, you see, that not all best practices are created equal. Some are much, much more important than others. And some are just better left out of the book, so that readers aren't distracted by "clutter." I hope that the result—this book—has an immediate and lasting impact. But even among the best practices I didn't reject, some stand out as being especially important—so I've decided to award these best
practices the following prizes:
Grand Prize SQL-00: Establish and follow clear rules for how to write SQL in your application. (See Chapter 6.) First Prize MOD-01: Encapsulate and name business rules and formulas behind function headers. (See Chapter 7.) Second Prize: Two Winners EXC-00: Set guidelines for application-wide error handling before you start coding. (See Chapter 5.) PKG-02: Provide well-defined interfaces to business data and functional manipulation using packages. (See Chapter 8.) Third Prize: Four Winners MOD-03: Limit execution section sizes to a single page using modularization.
(See Chapter 7.)DAT-15: Expose package globals using "get and set" modules. (See Chapter 3.) DEV-03: Walk through each other's code. (See Chapter 1.) STYL-09: Comment tersely with value-added information. (See Chapter 2.) If you follow each of these "best of the best" practices, you will end up with applications that are the joy and envy of developers everywhere!
About the Code The best way to learn how to write good code is by analyzing and following examples.
Almost every best practice offered in this book includes a code example, both in the text and in downloadable form from the Oracle PL/SQL Best Practices site, available
through the O'Reilly & Associates site at:
To locate the code for your best practice, simply enter the best practice identifier, such as BIP-10, in the search field. You will then be directed to the associated code.
You can also browse the site by topic area. You can even offer your own insights about PL/SQL best practices, so I encourage you to visit and contribute.
As a rule, I will follow my own best practices in these examples (unless the point of the code is to demonstrate a "bad practice"!). So, for example, you will rarely see me using DBMS_OUTPUT.PUT_LINE, even though this "show me" capability is needed in many programs. As I mention in [BIP-01: Avoid using the DBMS_OUTPUT.PUT_LINE procedure directly.], you should avoid calling this procedure directly; instead, build or use an encapsulation over
DBMS_OUTPUT.PUT_LINE. So rather than seeing code like this:
you will instead encounter a call to the "pl" or "put line" procedure:
I also make many references to PL/Vision packages. PL/Vision is a code library, consisting of more than 60 packages that offer 1,000-plus procedures and functions to perform a myriad of useful tasks in PL/SQL applications. I have deposited much of what I have learned in the last five years about PL/SQL into PL/Vision, so I naturally return to it for examples. Any package mentioned in this book whose name starts with "PLV" is a PL/Vision package.
A completely free, "lite" version of PL/Vision is available from the PL/SQL Pipeline