Comments about oreilly Java Database Best Practices:

Unwillinglly I have to say that this book presents very fluent but in the same time superficial reading matter. Probably the title is the most misleading part of it since everybody seeing "... Best Practices" expect that such a book is intended for very experienced readers willing to compare their own work with "generally accepted best practices". Contrary to it, this book is intended for newbies in database design and database application development. Athough there is some good general chapters, I really didn't expect to encounter in this book chapters like "SQL" explining basics of SQL language or similar newbie stuff. Many thing are only touched not witout deeper comparison or explanations with tests from existing works (that is practice for me).

Comments about oreilly Java Database Best Practices:

The first review of this book is probably in reference to a "Java Enterprise Best Pratices" since it was written before this book was published and since Ravi Mahalingam wrote the exact same review for that book.

This book is great for anyone who will be using a database in a java application. It will help any newcomer to avoid the pitfalls that som many others have fallen into. It gives a great overview of the different persistent models that are currently available, and shows examples of their uses.

Comments about oreilly Java Database Best Practices:

Bob,

I believe there is a bit of a misunderstanding related to your disagreements:

#1"It is not helpful to suggest to neophyte database developers that character PKs are desirable"

I agree entirely. In fact, I counsel against that on page 29 where I say, "I recommend the use of 64-bit, sequentially generated integers for primary key columns." I admit, I should have called this out in a sidebar as a best practice. Nevertheless, it is right at the front of the section on how to design primary keys.

The best practice you seem to be arguing against, however, is the following: "Use fixed character data types like CHAR for primary keys in lookup tables."

The important clause here is, "in lookup tables". This best practice is about how one deals with designing primary keys for lookup tables like Country, State, Locale, etc. For such tables you want a fixed character data type as the primary key. Fixed, because indexing and searching against variable length types is much less efficient and character because applications almost always primarily search lookup tables based on human readable codes. The alternative would be to create a State table like this:

CREATE TABLE State (

state_id BIGINT NOT NULL PRIMARY KEY,

code CHAR(2) NOT NULL,

name VARCHAR(50) NOT NULL,

UNIQUE INDEX ( code ) );

This approach would have zero performance or design benefit, add additional application complexity, reduce end user usability, and require an extra, useless index.

In short, I strongly stand by this best practice as it is in the book. #2 "including the name of a table in the primary key is done to make things easier when using CASE tools" Personally, I do not like the fact that CASE tools are easier to work with when you follow this best practice. I hate redundant naming, which is what this best practice causes. However, the fact remains that it is easier to work with, and more important, collaborate in CASE tools when you follow this best practice. Even if you do not use a CASE tool, this best practice does no harm to maintainability, efficiency, or functionality of the model--the primary things you attempt to impact with a best practice. I thus stand by this practice even though I find the need for it annoying. #3 "I also feel that of all the CDs that could have been used in table 2-1, the author could have chosen more neutral examples to be used to illustrate business data and sample queries." I have two points to make regarding this issue.

First, what I like about O'Reilly books is that they contain a little bit of the personality of the authors in them. That is also why I begin the chapters with quotes from philosophers. By including examples from my music tastes, I am adding a bit of my personality to the book. And there is nothing offensive in any of these titles. In fact, they should be familiar to most of my audience, especially those with even a passing familiarity with Punk, New Wave, Industrial, and Alternative rock.

The Cure's Pornography is universally acclaimed as the Cure's most important work. And the Cure is one of the

most influential bands to modern rock, pop and alternative. Though, admittedly, modern pop is more influenced by Disintegration and Wish than Pornography.

Garbage, on the other hand, is a very popular modern band. One of their song's is the theme to the James Bond movie The World Is Not Enough.

On a final note, I have included this CD example in both editions of Database Programming with JDBC and Java and the only negative comment I have ever heard was from a professional reviewer rightfully complaining about me misspelling the name of the Sex Pistols album. I hope this response clears up some confusion.

George

Comments about oreilly Java Database Best Practices:

**** Sample chapter feedback ****

I saw the following statement in another review of this book:

Unlike most other books, this book is produced by Java experts

This is evident. As the database sample chapter did do a fair job of expressing goals of normalization and provided useful examples and commentary, the entire section regarding table design and primary keys is flawed. There are a number of sidebars labeled "best practice" which do not promote any best practices I am aware of. It is not helpful to suggest to neophyte database developers that character PKs are desirable, that multi-part PKs are tolerated, and that including the name of a table in the primary key is done to make things easier when using CASE tools. There are some appropriate suggestions such as using integrity constraints and cautioning against one-to-one relationships.

I also feel that of all the CDs that could have been used in table 2-1, the author could have chosen more neutral examples to be used to illustrate business data and sample queries. I'm not a prude, but I cannot share titles like "Pornography" and "Garbage" and discuss them (as example data) with my students because it may offend someone and put them off the subject. As it is presented, this book seems unsuitable even as a supplemental text for training. It may be of value to those who have few expectations of the quality or integrity of their persistent storage designs.

Please bring back Dave Ensor and Ian Stevenson! These guys understood and explained "best practice" very well in their O'Reilly title "Oracle Design".

Comments about oreilly Java Database Best Practices:

Unlike most other books, this book is produced by Java experts. the book assumes prior knowledge of the topics and does not intend to take a beginner from ignorance to knowledge.

This book is not intended for beginners but experts in the Java domain designing enterprise level systems or even maintaining them for system

performance and enhancements.

The book is well written and all the potential gotchas and the mistakes commonly done in application design and development are outlined with appropriate alternate solutions.

The book covers all aspects of java and ejb application development and their best practices.

Overall, this a good book to have and will be used by experienced java developers and the not so experienced.