5
1
Paperback(Second Edition)
$29.99
-
PICK UP IN STORECheck Availability at Nearby Stores
Available within 2 business hours
Related collections and offers
29.99
In Stock
Overview
In this compact book, Steven Feuerstein, widely recognized as one of the world's leading experts on the Oracle PL/SQL language, distills his many years of programming, teaching, and writing about PL/SQL into a set of best practices-recommendations for developing successful applications. Covering the latest Oracle release, Oracle Database 11gR2, Feuerstein has rewritten this new edition in the style of his bestselling Oracle PL/SQL Programming. The text is organized in a problem/solution format, and chronicles the programming exploits of developers at a mythical company called My Flimsy Excuse, Inc., as they write code, make mistakes, and learn from those mistakes-and each other. This book offers practical answers to some of the hardest questions faced by PL/SQL developers, including:
- What is the best way to write the SQL logic in my application code?
- How should I write my packages so they can be leveraged by my entire team of developers?
- How can I make sure that all my team's programs handle and record errors consistently?
Product Details
ISBN-13: | 9780596514105 |
---|---|
Publisher: | O'Reilly Media, Incorporated |
Publication date: | 10/01/2007 |
Edition description: | Second Edition |
Pages: | 292 |
Product dimensions: | 6.00(w) x 9.00(h) x 0.50(d) |
About the Author
Steven Feuerstein is considered one of the world's leading experts on the Oracle PL/SQL language. He is the author or coauthor of Oracle PL/SQL Programming, Oracle PL/SQL Best Practices, Oracle PL/SQL Programming: Guide to Oracle8i Features, Oracle PL/SQL Developer's Workbook, Oracle Built-in Packages, Advanced Oracle PL/SQL Programming with Packages, and several pocket reference books (all from O'Reilly & Associates). Steven is a Senior Technology Advisor with Quest Software, has been developing software since 1980, and worked for Oracle Corporation from 1987 to 1992.
Table of Contents
Dedication; Preface; Why Best Practices?; The Cast of Characters; Structure of This Book; How to Use This Book; Conventions Used in This Book; About the Code; Comments and Questions; Safari Books Online; Acknowledgments; Chapter 1: The Big Picture; 1.1 Successful Applications Are Never an Accident; 1.2 Best Practices for Successful Applications; 1.3 Software is like ballet: choreograph the moves or end up with a mess.; 1.4 Deferred satisfaction is a required emotion for best practices.; 1.5 Contracts work for the real world; why not software, too?; 1.6 Don't act like a bird: admit weakness and ignorance.; 1.7 Five heads are better than one.; 1.8 Don't write code that a machine could write for you instead.; 1.9 We need more than brains to write software.; Chapter 2: Real Developers Follow Standards; 2.1 Best Practices for Developing and Using Standards; 2.2 It's a free country; I don't have to use carriage returns in my code.; 2.3 Too much freedom is a very bad thing.; 2.4 Good names lead to good code.; 2.5 Put your checklists into your code.; 2.6 Who needs comments? My code is self-documenting!; Chapter 3: Life After Compilation; 3.1 Testing, Tracing, and Debugging; 3.2 Best Practices for Testing, Tracing, and Debugging; 3.3 Thanks, but no thanks, to DBMS_OUTPUT.PUT_LINE!; 3.4 Assume the worst, and you will never be disappointed.; 3.5 Users really don't want to be programmers.; 3.6 Do you take road trips without a destination in mind?; 3.7 For every test you can think of, there are 10 tests waiting to be performed.; 3.8 Sherlock Holmes never had it so good.; Chapter 4: What's Code Without Variables?; 4.1 Best Practices for Declaring Variables and Data Structures; 4.2 That column's never going to change!; 4.3 There's more to data than columns in a table.; 4.4 I take exception to your declaration section.; 4.5 Best Practices for Using Variables and Data Structures; 4.6 This logic is driving me crazy!; 4.7 Go ahead and splurge: declare distinct variables for different usages.; 4.8 Didn't your parents teach you to clean up after yourself?; 4.9 Programmers are (or should be) control freaks.; 4.10 Best Practices for Declaring and Using Package Variables; 4.11 Danger, Will Robinson! Globals in use!; 4.12 Packages should have a strong sense of personal space.; Chapter 5: Developer As Traffic Cop; 5.1 Best Practices for Conditional and Boolean Logic; 5.2 Reading your code should not require mental gymnastics.; 5.3 KISS (Keep it Simple, Steven).; 5.4 Beware the hidden costs of NULL.; 5.5 Best Practices for Loop Processing; 5.6 There's a right way and a wrong way to say goodbye.; 5.7 Don't take out "programmers' insurance" . . . and don't worry about SkyNet.; 5.8 There is more than one way to scan a collection.; 5.9 Best Practices for Branching Logic; 5.10 Maze-like programs are never a good thing.; Chapter 6: Doing the Right Thing When Stuff Goes Wrong; 6.1 Best Practices for Understanding Error Handling; 6.2 Ignorance is bad exception management.; 6.3 All exceptions are not created equal.; 6.4 One error management approach for all.; 6.5 Best Practices for Nitty-Gritty, Everyday Exception Programming; 6.6 Your code makes me feel dumb.; 6.7 Avoid programmer apathy.; 6.8 Best Practices for Coding Defensively; 6.9 You weren't supposed to do that with my program!; Chapter 7: Break Your Addiction to SQL; 7.1 SQL Is Bad!; 7.2 General SQL Best Practices; 7.3 The best way to avoid problematic code is to not write it.; 7.4 You may write PL/SQL code, but SQL always takes precedence.; 7.5 When one transaction is not enough.; 7.6 I don't always want to save my changes.; 7.7 Best Practices for Querying Data from PL/SQL; 7.8 It's always better to fetch items into a single basket.; 7.9 Answer the question being asked; that is, be a good listener.; 7.10 Your code makes my head spin.; 7.11 Best Practices for Changing Data from PL/SQL; 7.12 Assume the worst!; 7.13 Things only get more complicated over time.; 7.14 Timing is everything in the world of cursors.; 7.15 Best Practices for Dynamic SQL; 7.16 Make it easy to untangle and debug your dynamic SQL statements.; 7.17 Give the RDBMS a break.; 7.18 So you think you know what users might do with your code?; 7.19 It's rude to drop someone else's objects.; Chapter 8: Playing with Blocks (of Code); 8.1 Best Practices for Parameters; 8.2 Once a program is in use, you can't change it willy-nilly.; 8.3 What the heck do those parameter values mean?; 8.4 Where'd that data come from?; 8.5 Best Practices for Procedures and Functions; 8.6 Write tiny chunks of code.; 8.7 Every program should be an island (of purpose).; 8.8 Gifts should always come tightly wrapped.; 8.9 One way in, one way out: multiple exits confuse me.; 8.10 Black or white programs don't know from NULL.; 8.11 Best Practices for Packages; 8.12 Where there is one program, there will soon be two.; 8.13 "Easy to use code" is code that is used—and reused.; 8.14 Best Practices for Triggers; 8.15 Uncertainty in trigger execution is a most unsettling emotion.; 8.16 "One-stop triggering" is so much easier to understand and maintain.; 8.17 Your application should not be able to perform a "Houdini" with business rules.; Chapter 9: My Code Runs Faster Than Your Code; 9.1 Best Practices for Finding Slow Code; 9.2 Take the guesswork out of optimization.; 9.3 There are so many ways to implement an algorithm; which is best?; 9.4 Best Practices for High-Impact Tuning; 9.5 Let Oracle do most of the tuning for you.; 9.6 Who has time for querying (or inserting or deleting or updating) one row at a time?; 9.7 If the SGA is so wonderful, why not emulate it?; 9.8 When waiting is not an option...; 9.9 Best Practices for Other Tuning; 9.10 Sometimes "safe programming" is a little too slow.; 9.11 PL/SQL loops should not resemble hamsters running in circles.; 9.12 Tailor-made datatypes are the best fit for your programs.; Best Practices Quick Reference; Resources for PL/SQL Developers; Book Example Files; Books and Other Content; Free Software; Colophon;From the B&N Reads Blog
Page 1 of