Rating: 
Summary: Well worth the price
Review: 1. I do not follow every practice in this book.
2. Only some of those I don't follow do I think I should follow.
3. All of the practices strike me as at least arguable.It does what it sets out to do. I believe that it will help the reader use PL/SQL more effectively. In the next edition, I'd like to see a section on unit testing, using the utPLSQL system that Feuerstein is managing the development of.
Rating: 
Summary: No useful information for midlevel and up programmers.
Review: Come on guys! We are mature professionals (at least I am: my paycheck as a consultant in 'fortune 500' let me to believe so). We do it for a living. I mine coding in PL/SQL. After all, I don't care too march about Steve's political view on Middle East peace process. I had seeing 'Israeli military occupation' from very close range for years, and I know this topic march better then he is. I hate what he likes and I have very good reasons to. But we are talking about Oracle PL/SQL and "Best Practices" to write code in it. PL/SQL is not a Basic (or Visual Basic). If you have to code in it, it's mine you are professional programmer (or you pretend to be one). I am about 3 years in software development. Now I have to develop set of extensions to Oracle backend. Working with Oracle has two major problems: 1. Complicity as a side effect of flexibility. 2. Lack of ability to see implementation code of the server. I am looking for answer to questions of this kind: when I should prefer SQL functions DECODE(), GREATEST(), LEAST() etc. versus writing custom PL/SQL function, how to insure the best optimization by server when I am writing PL/SQL code, how to force Oracle to prefer one optimization scenario versus anther, and how not to overuse it. I didn't find discussions of these topics in "Oracle PL/SQL Best Practices" attempted to experienced PL/SQL developers, but I found two pages (~p.53) discussion about writing IF statement: "IF My_Boolean = TRUE THEN..." is not as good as "IF My_Boolean THEN...", and "My_Boolean := My_Number > 0 ;" is march better then "IF My_Number > 0 THEN My_Boolean := TRUE ELSE My_Boolean := FALSE;". I found very verbose statements about importance of comments, using consistent naming convention, good testing, code cleanup, and code review. These discussions would appropriate in an entry-level text, college textbook, or project management title. With my just and only 3 years in software development (using PL/SQL for one month in did) I didn't find any new useful information in this book. About O'Reilly & Associates publishing practice: I own number of titles from this print house. And I am completely satisfied with them. But in this case I have a problem: I think technical paper it is not appropriate place to declare or to even show authors or editors political preferences. By putting highly politically colored author's dedication on the first page they made me (potential buyer) to avoid this title in any case, even if I will be desperately needed it. I don't think it was a smart business decision to do this, if it was a political decision its even les smarter.
Rating:
Summary: No useful information for midlevel and up programmers.
Review: Common gays! We are mature professionals (at least I am: my paycheck as a consultant in 'fortune 500' let me to believe so). We do it for a living. I mine coding in PL/SQL. After all, I don't care too march about Steve's political view on Middle East peace process. I had seeing 'Israeli military occupation' from very close range for years, and I know this topic march better then he is. I hate what he likes and I have very good reasons to. But we are talking about Oracle PL/SQL and 'Best Practices' to write code in it. PL/SQL is not a Basic (or Visual Basic). If you have to code in it, it's mine you are professional programmer (or you pretend to be one). I am about 3 years in software development. Now I have to develop set of extensions to Oracle backend. Working with Oracle has two major problems: 1. Complicity as a side effect of flexibility. 2. Lack of ability to see implementation code of the server. I am looking for answer to questions of this kind: when I should prefer SQL functions DECODE(), GREATEST(), LEAST() etc. versus writing custom PL/SQL function, how to insure the best optimization by server when I am writing PL/SQL code, how to force Oracle to prefer one optimization scenario versus anther, and how not to overuse it. I didn't find discussions of these topics in 'Oracle PL/SQL Best Practices' attempted to experienced PL/SQL developers, but I found two pages (~p.53) discussion about writing IF statement: 'IF My_Boolean = TRUE THEN'' is not as good as 'IF My_Boolean THEN'', and 'My_Boolean := My_Number > 0 ;' is march better then 'IF My_Number > 0 THEN My_Boolean := TRUE ELSE My_Boolean := FALSE;'. I found very verbose statements about importance of comments, using consistent naming convention, good testing, code cleanup, and code review. These discussions would appropriate in an entry-level text, college textbook, or project management title. With my just and only 3 years in software development (using PL/SQL for one month in did) I didn't find any new useful information in this book. About O'Reilly & Associates publishing practice: I own number of titles from this print house. And I am completely satisfied with them. But in this case I have a problem: I think technical paper it is not appropriate place to declare or to even show authors or editors political preferences. By putting highly politically colored author's dedication on the first page they made me (potential buyer) to avoid this title in any case, even if I will be desperately needed it. I don't think it was a smart business decision to do this, if it was a political decision its even les smarter.
Rating:
Summary: Excellent resource for new or experienced PL/SQL programmers
Review: I found this book to be an excellent (re-)introduction to good programming practices in PL/SQL. After reading the first few pages a little defensively ("I don't make those sorts of mistakes do I?") I soon realised that there was much to learn in this book as well as much that I had forgotten. This book has lead to an instant improvement in the quality of my PL/SQL code. I particularly like the Quick Reference card in the back of the book.
Rating:
Summary: Excellent resource for new or experienced PL/SQL programmers
Review: I found this book to be an excellent (re-)introduction to good programming practices in PL/SQL. After reading the first few pages a little defensively ("I don't make those sorts of mistakes do I?") I soon realised that there was much to learn in this book as well as much that I had forgotten. This book has lead to an instant improvement in the quality of my PL/SQL code. I particularly like the Quick Reference card in the back of the book.
Rating:
Summary: Excellent resource for new or experienced PL/SQL programmers
Review: I found this book to be an excellent (re-)introduction to good programming practices in PL/SQL. After reading the first few pages a little defensively ("I don't make those sorts of mistakes do I?") I soon realised that there was much to learn in this book as well as much that I had forgotten. This book has lead to an instant improvement in the quality of my PL/SQL code. I particularly like the Quick Reference card in the back of the book.
Rating:
Summary: Wisdom in a Package
Review: I have been an avid reader of Steven's books ever since I started learning PL/SQL as part of my career in Oracle. Without a doubt he is an authority on this proprietary language from Oracle and has a vast repository of code that he can proudly claim his own. This book is ideal for those who have experience working with applications built on Oracle. You may have encountered situations in which you probably chose an approach to solve a problem or get something done in a hurry without thinking through the implications on performance or taking recourse to some useful features in PL/SQL. These practices classified by topic will not only explain the wisdom but also illustrate how to use it. Make sure you keep it handy and follow these guidelines religiously in your application code. Hats off to Steven and O'Reilly for another useful title !
Rating: 
Summary: 2nd review
Review: I've been feeling guilty for giving this book only one star, so here's a second try.
I was disappointed by this book because I was able to speed read most of it. In other words, it did not present much that I had not seen before.
Some parts of the book seem to be a direct (literal?) translation of OOP design methodology. It would have been interesting if the author had spent some effort examining the OOP language features which are lacking in PL/SQL, in order to adapt the methodology. Ex.1: OOPL compilers can make small function calls 'inline', meaning that they are expanded as if they were macros, to avoid the function call overhead. I do not believe this exists in PL/SQL. If it does, the author should mention it when he suggests using wrapper functions. If it doesn't, then he should make the reader aware of the performance cost, which in some cases might still be ok, anyway.
Ex.2: The methodology he proposes leads to a proliferation of methods and classes. OOPLs have language structures to make them manageable (e.g. namespaces in C++, packages in Java). PL/SQL has the further disadvantage that it does not allow you to re-group your logic inside executables, DLLs, component objects, or even inside directories.
Still, this book should be quite beneficial to someone who is new to structured programming. It also isn't very expensive.
Rating:
Summary: for beginners, maybe
Review: If PL/SQL is your very 1st language, ever, you may find this book interesting. Otherwise, read its equivalent for an object-oriented language, or even C, Fortran, VB, Pascal, you name it. Just as structured programming in Fortran is dull, so it is with PL/SQL (if not more so). Any knowledge you have for a more complex procedural language is easy to apply. Having read the whole book, I'm afraid that only one page out of 182 actually had anything that was of interest to me (NOCOPY option for IN OUT parameters). The author seemed to be struggling to find enough to fill his book. If you want a quick perusal of interesting language features, read something like the author's PL/SQL pocket reference. As an aside, I would even criticize the applicability of some of what is prognosticated in this book, simply because PL/SQL is not meant to be used to write a hugely complex application. After all, Oracle put Java in the database for just such a situation. There is a law in 'increasing returns' when you use good programming practices, and the code bloat in PL/SQL project sizes applicable to the language would not be worth it. Ex.: replacing the one line 'SELECT patient_seq.NEXTVAL INTO my_id FROM dual' with a function 'next_patient_id' that takes ten lines of code to write! What kind of PL/SQL programmer would rather have a function call hide the fact that the id comes from a sequence, anyway? What about the overhead of placing the function call itself? My final beef is that there is no index in this book. What possible excuse/justification/rationalization is there for that? Lucky for me I just need to do a search for 'nocopy parameter pl/sql' in Google to get what I need :P
Rating:
Summary: for beginners, maybe
Review: If PL/SQL is your very 1st language, ever, you may find this book interesting. Otherwise, read its equivalent for an object-oriented language, or even C, Fortran, VB, Pascal, you name it. Just as structured programming in Fortran is dull, so it is with PL/SQL (if not more so). Any knowledge you have for a more complex procedural language is easy to apply. Having read the whole book, I'm afraid that only one page out of 182 actually had anything that was of interest to me (NOCOPY option for IN OUT parameters). The author seemed to be struggling to find enough to fill his book. If you want a quick perusal of interesting language features, read something like the author's PL/SQL pocket reference. As an aside, I would even criticize the applicability of some of what is prognosticated in this book, simply because PL/SQL is not meant to be used to write a hugely complex application. After all, Oracle put Java in the database for just such a situation. There is a law in 'increasing returns' when you use good programming practices, and the code bloat in PL/SQL project sizes applicable to the language would not be worth it. Ex.: replacing the one line 'SELECT patient_seq.NEXTVAL INTO my_id FROM dual' with a function 'next_patient_id' that takes ten lines of code to write! What kind of PL/SQL programmer would rather have a function call hide the fact that the id comes from a sequence, anyway? What about the overhead of placing the function call itself? My final beef is that there is no index in this book. What possible excuse/justification/rationalization is there for that? Lucky for me I just need to do a search for 'nocopy parameter pl/sql' in Google to get what I need :P
| 
