Hugendubel.info - Die B2B Online-Buchhandlung 

Merkliste
Die Merkliste ist leer.
Bitte warten - die Druckansicht der Seite wird vorbereitet.
Der Druckdialog öffnet sich, sobald die Seite vollständig geladen wurde.
Sollte die Druckvorschau unvollständig sein, bitte schliessen und "Erneut drucken" wählen.

Oracle PL/SQL Best Practices

Write the Best PL/SQL Code of Your Life
BuchKartoniert, Paperback
292 Seiten
Englisch
O'Reilly Mediaerschienen am27.11.20072nd edition
Summarizes PL/SQL practices in nine categories such as overall PL/SQL application development; programming standards; program testing, tracing, and debugging; variables and data structures; control logic; error handling; the use of SQL in PL/SQL; building procedures, functions, packages, and triggers.mehr
Verfügbare Formate
BuchKartoniert, Paperback
EUR30,00
E-BookEPUBDRM AdobeE-Book
EUR19,99
E-BookPDFDRM AdobeE-Book
EUR25,49
E-BookPDFDRM AdobeE-Book
EUR14,99
E-BookEPUBDRM AdobeE-Book
EUR11,99

Produkt

KlappentextSummarizes PL/SQL practices in nine categories such as overall PL/SQL application development; programming standards; program testing, tracing, and debugging; variables and data structures; control logic; error handling; the use of SQL in PL/SQL; building procedures, functions, packages, and triggers.
Details
ISBN/GTIN978-0-596-51410-5
ProduktartBuch
EinbandartKartoniert, Paperback
FormatTrade Paperback (USA)
Erscheinungsjahr2007
Erscheinungsdatum27.11.2007
Auflage2nd edition
Seiten292 Seiten
SpracheEnglisch
MasseBreite 154 mm, Höhe 234 mm, Dicke 20 mm
Gewicht393 g
Artikel-Nr.10809121

Inhalt/Kritik

Inhaltsverzeichnis
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;mehr

Autor

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.