Supplemental files and examples for this book can be found at http://examples.oreilly.com/9780596514105/. Please use a standard desktop web browser to access these files, as they may not be accessible from all ereader devices.
All code files or examples referenced in the book will be available online. For physical books that ship with an accompanying disc, whenever possible, weve posted all CD/DVD content. Note that while we provide as much of the media content as we are able via free download, we are sometimes limited by licensing restrictions. Please direct any questions or concerns to .
Preface
I love getting started on new projects (and I include working on new editions of existing books in that general category). It is the perfect opportunity to say to myself: "I am going to get it right this time!"
That fantasy usually persists only for days (or maybe weeks) into a project before it fades, but in the case of the second edition of Oracle PL/SQL Best Practices , I managed to live out my fantasy all the way through. You are holding the result in your hands, and I hope you enjoy reading and learning from it as much as I enjoyed writing it.
Here's how I managed this remarkable feat: I took a vow to not let best practices get boring.
Now, don't get me wrong. I liked the first edition of this book, and so did its many readers. Yet in hindsight, I feel as if I took a right turn when I should have kept going straight. My first book, Oracle PL/SQL Programming , has been extremely popular over the years, and many people have told me how much they like the sense of humor, the anecdotes, and the many detailed examples.
Several years after the publication of Oracle PL/SQL Programming , I wrote Oracle PL/SQL Best Practices . And somehow, for reasons I cannot recall, I managed to make this book a somewhat preachy and rigidly structured text. Luckily for me, developers seem to like lots of structure and don't mind too much being preached at by people they trust!
But as I considered revamping this book for its second edition, I found myself thinking: best practices are really important, but that doesn't mean they have to be seriousthey can be fun and entertaining (as much for me to write as for you to read)!
So that's what I did: I had fun writing this book. I sacrificed some of the rigidity of structure, emphasized practicality over theoretical usefulness, and generally came down off my perch (don't worrythere are still more than enough rants and soapboxing!). In this second edition, I've tried to make the discussion a lot more interesting by sharing many of my ideas about best practices through stories about the successes and failures of the employees of the fictitious company, My Flimsy Excuse, Inc., and the adventures of its development team (the members of the team are described later in the Preface). Of course, I have also updated the text to keep pace with Oracle Corporation's implementation of new PL/SQL features, including those in Oracle Database 11 g .
Why Best Practices?
My intention with this book is to provide you with a set of best practices guidelines for building programs and applicationsthat will improve (and, I hope, transform ) the PL/SQL code you write. Some of these best practices are high-level recommendations for how to approach designing and writing your overall applications. Other best practices are much more oriented to day-to-day programming practice. In most of my recommendations, I include references to code or tools that you can download that will make it easier for you to apply these recommendations.
, The Big Picture , covers the high-level recommendations for writing high-quality code. The remaining chapters of the book explore how to apply specific guidance to the everyday realities of software development. Before we delve into these specific recommendations, though, I would like to take advantage of this Preface to offer some thoughts on the role of software developersand the nature of our jobsin the big, wide world "out there" beyond our code.
Best Practices and the Real World
Clearly, software developers want to (and should) pay attention to best practices so that they will be able to create more successful applications. I also believe, however, that the responsibility of developers goes well beyond the specific projects on which they are working.
After all, you are one of the people who make software possible , who therefore make computer systems like the Internet possible. That is an awesome amount of power, but as Spider Man's uncle tells us, "With great power comes great responsibility."
From this perspective, it is very important to understand that you are not just a cog in the corporate wheel. When you are told to write a program, you should engage fully with that request. You should make sure not only that you understand in detail what it is the user wants you to write, but also that you appreciate how this program will meet its business objectives.
As a programmer, you are trained to think logically about the challenges in front of you. This rational thought process is not something to be taken for granted. Many other humans have never received such training and don't know how to reason their way through complex and thorny problems. Given this background, you can often help your users more clearly understand their own roles and their own challenges.
Your responsibility also extends beyond business objectives. You have an ethical responsibility to make sure that the software you write will not cause harm. Let's face it: executives of companies cannot always be trusted to do the right thing for their customers, for the company and its employees, and for society at large. Let's not forget the terrible lessons learned from Enron, Arthur Andersen, Union Carbide, Halliburton, and so many others. If you write software that enables executives in your firm to break the law or simply take advantage of those less fortunate, then you are complicit in that unethical behavior.
Of course, most of us will never be placed in such an ethical quandary. Instead, our main challenge will be to remember how much humanity depends on software, and how much we can all be hurt by buggy software, software that is not secure, and software that is simply badly designedprograms that waste the time of users and greatly increase their stress levels.
They Call This "Work"?
Can you really call what we do work ? Most people on this earth work very hard in exchange for a paycheck. They drive buses, clean sewers, work in factories, pick vegetables and fruit under a blazing sun, teach children, take care of sick peoplehard work that often takes a toll on their health and well-being. We, on the other hand... what do we do? Here are a variety of ways to characterize our "work":
Programming as poetryWe sit around in nice, air-conditioned offices or cubicles. We think about things and write them down (or type them). And for this we get a paycheck. It's like getting paid to write poetry (and some of us actually do feel that our programs are a form of poetry).