Java Database Best Practices

ProfKyne writes "I was excited to read this book when I first noticed it listed as "coming soon" in the Java section of O'Reilly's site back in May. I downloaded and read the sample chapter and waited expectantly for the book to be released. I was hoping that this book would be perfect for me, as nearly all of the Java programming I have done has dealt in some way with database access, though I do not consider myself to be an expert on the subject. The book didn't disappoint; Java Database Best Practices is an excellent high-level guide to writing database-driven applications from Java." Read on for the rest of ProfKyne's review. Java Database Best Practices author George Reese pages 267 publisher O'Reilly Associates rating Excellent for Java programmers moving to J2EE reviewer Erik Price ISBN 0596005229 summary A high-level introduction to writing database-driven apps in Java

What it's about: The book is divided into three sections of several chapters each:

1. Data Architecture - an introduction to database-driven application concepts
2. Persistence Fundamentals - descriptions of the various persistence frameworks for Java application development
3. Tutorials

I should note that the book follows a strange order: the most logical progression for the apparent target audience of this book (developers just getting into J2EE) would be to read Part 1 first, then Part 3, and then Part 2, as the "Persistence Fundamentals" section draws heavily on content introduced in the later "Tutorials" section.

The first section (Data Architecture) introduces some of the concepts that will be covered in greater depth later on in the book, but also contains an excellent chapter, "Relational Data Architecture," on database schema design and normalization. By the way, this is the sample chapter that can be downloaded from O'Reilly's site. In fact, this chapter set itself apart from the rest of the book in that it goes into a great deal of detail on its subject (although obviously an aspiring DBA should probably read whole books dedicated to the topic of relational database concepts). Most of the rest of the chapters in the book is somewhat more lightweight than "Relational Data Architecture." This section also contains a chapter that introduces some of the things to be aware of when managing transactions, including implementation tips on using transactions in JDBC programming such as optimistic locking and the various transaction types (dirty reads, etc).

The Persistence Models section focuses on different persistence frameworks, there is a chapter for each of the following: Persistence Fundamentals, EJB Container-Managed Persistence (covers 1.x and 2.0 models), EJB Bean-Managed Persistence, JDO, and "Alternative Persistence." The fundamentals chapter is where some of the best of the "best practices" of the book are found, and introduces such patterns as the Data Access Object pattern and the Memento pattern in the context of a simple guest book JSP application. The EJB chapters do assume that the reader has a basic understanding of how EJB works, and provides suggestions and guidance on ways to implement EJBs in real J2EE applications. (Don't worry, if you don't know about EJBs, the J2EE Tutorial chapter later in the book provides this.) The JDO section is one of the shortest in the book; I think that it's just such a new technology (in terms of available implementations) that most of the "best practices" are yet to be discovered. "Alternative Persistence" means Hibernate and Castor.

The Tutorials section is definitely not for advanced Java programmers, as it contains beginner-level introductions to the J2EE platform, the SQL language, the JDBC architecture, and the JDO API. If you really don't know anything about JNDI or servlets or EJB, then the J2EE chapter is written for you -- it's not a "how-to" tutorial, but rather a description of the basic concepts. The JDO tutorial is like the J2EE tutorial, introducing the basic concepts such as "the extent" and the filter language used to query for JDO-persisted objects, but I think partly because it's such a new technology, there's not a lot of detail here. You'll still have to read more about J2EE EJB, or JDO, if you decide to use them in a production application. On the other hand, you will learn how to make effective use of SQL queries and the JDBC API (which lets you execute SQL queries from your Java code) from their respective tutorials.

While this is a good start, you will eventually want something more in-depth than this if you are actually implementing a J2EE application (such as a book dedicated to servlet/JSP programming or Enterprise JavaBean development). But I really wish that I had read Java Database Best Practices before tackling these subjects, as it would have helped ease the transition

What's to like As strange as it may sound, one of the things I liked most about the book is that it is relatively thin. In other words, the author gets right to the point and doesn't waste excessive space replicating information that can be found elsewhere. For instance, when describing how to implement a database-independent sequencing component, he incorporates enough code to support what he's saying, but doesn't include page after page of complete code listing, intact with multi-line Javadocs and plenty of whitespace -- just the meat. You can download all of the code from O'Reilly's site in a zip archive (and yes, it does include the Javadocs and whitespace that are wisely omitted from the book). Ironically, the book costs no less than other offerings from O'Reilly that are twice as thick.

Also, the "best practices" in the book are very good and, at least in my case, I was not familiar with some of them, so it was very worthwhile reading. As an example, I myself have recently run into the problem of different sequencing systems on different databases (such as MySQL's AUTO_INCREMENT column type vs PostgreSQL's sequence types). I've worked around it by modifying the application's database calls, but that isn't really a good strategy. Implementing a sequencer at the application level (one of the "best practices") is a much better idea if you're not clustering your application servers and other applications will not be performing INSERTs into the database. On the other hand, if clustering is an issue, then it's probably a better idea to use EJBs, and if other applications will be writing to the data store, then database portability will be difficult in the first place (even with the help of Perl's DBI or PHP's PEAR DB abstraction). Some of the other excellent best practices introduced are the DAO pattern and database schema normalization coverage.

What's to consider The most important thing to know when considering this book is that it really struck me as being appropriate for novice J2EE developers and/or those who are new to database programming in general. First of all, I think it's safe to assume that most people who will be doing anything with databases in Java will be using at least some element of the J2EE platform, and this book makes that same assumption. Java's tremendous success right now is in server-side application development. This means there won't be as much useful information in this book for the folks who are writing, say, an AWT interface tightly coupled to a MS-Access database through ODBC calls. Second of all, the patterns and practices described in this book should be familiar to most people who are already architecting J2EE applications, and are covered in greater depth in other books on enterprise application development.

Having now covered the main consideration, I do have to pick a couple of nits. Firstly, this book does suffer from a few of the editing problems that plague nearly all computer books (yes even the O'Reilly books) in their first printing. It's kind of embarrassing, but even in the sample chapter I found a somewhat bizarre mistake near the end, where a class diagram is drawn up using ERD notation instead of UML. Fortunately, there aren't too many technical errors like this. Another bone to pick was the author's choice to use a hideous scriptlet-heavy JSP instead of a servlet forwarding to a JSP in the small Guest Book application in "Persistence Fundamentals." I know that this is Java Database Best Practices, not Java Model View Controller Best Practices, but scriptlets are both difficult to read and quite frankly scorned as J2EE moves toward JSTL and JSP 2.0. It's a little too bad that View and Controller are mixed up in this example, because the author does an excellent job of explaining how to implement the Model using the Data Access Object pattern.

Finally, I have a feeling this book was named "Java Database Best Practices" for marketing reasons, perhaps to go with O'Reilly's other offering, "Java Enterprise Best Practices". While this is an excellent book about Java database programming, and there are indeed dozens of "Best Practice" tips strewn throughout the book, I think a better name for this book would have been "Java Database Fundamentals."

The summary I didn't want to simplify and rehash the book's "best practices" contents in this review, but rather provide prospective readers with an idea of what to expect from this book. Personally, I got a lot out of the book, but if you've already implemented bean-managed persistence in your EJBs using JDO, then you've probably already gotten past the point where this book is going to be a big help. In your case, it might be worth having around the office if you can get the company to pay for it. However, for those who have learned the Java language and want to get more involved in server-side application development, you're going to want to make sure you're familiar with all of these concepts and this book is the perfect way to get started with that. Where to find more info I'm not going to replicate the table of contents or any of the content in the book, because all of that information as well as the excellent sample chapter are available from O'Reilly's site. I purchased the book from SoftPro Books in Massachusetts (US), a bookstore for computer geeks. This is a good place to peruse the book if you're still riding the fence.

You can purchase the Java Database Best Practices from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

Sample chapter slashdotted

[Anonymous Coward]

But google cache also caches pdf files, and you can read the google version without a pdf viewer

Best Practices in IT

[yintercept]

People have been using the term "best practices" in IT for as long as I can remember.

Don't talk about "Best Practices", talk about the real issues: Security, Reliability, Robustness.

Let's see: Security. The biggest issue in security is generally the people...how they define passwords, what things they let go through firewalls, what things they should and shouldn't do. The security expert cannot completely make a network safe...they must define a best practices and go from there.

Reliability: I may be totally off base, but it seems to me that consistency is a factor in reliability. Assuring that things are written in a consistent manner generally involves defining best practices. I have seen many programs fail because a coder used inconsistent naming conventions.

Likewise Robustness seems to follow from having defined best practices.

n-tier applications

[msobkow]

Multi-tiered applications still require database code, database locking, and data sharing. While the client does not have access to a cursor or "scrollable result set", those features are still used at the back end where the system interfaces to the persistant storage (RDBMS.) Caching them as an array is only viable if the data is stable during your application's execution (lookups), or if your application is the only one accessing the database.

I agree that using application code to implement locking or sequencers is a poor approach. If those features are required, use a real database that supports them. Butchering an application design to work around limitations of less-robust databases like MySQL is foolish when you can get the desired functionality for free with products like PostgreSQL or a commercial database. It will also save you a lot of coding and debug time, letting you focus on application functionality, not infrastructure features.

Re:"Best Practices"

[kin_korn_karn]

Thanks for the thoughtful response.

I think a lot of us react negatively because Best Practices are often pushed by architect types that don't write code but they have all the Best Practice books and they use those to evaluate your output. In other words, they can be used as a crutch for the unknowledgable.

Also, there are the questions of "just who decided that these were the Best Practices anyway?" and "What exactly about them makes them Best?" Those are questions that aren't usually answered before the Best Practice is pushed on you.

Some developers have egos that keep them from from using any sort of guide to coding past the learning stage. These people feel that if you always follow a "Best Practice", coding becomes little more than cutting and pasting. I'm guilty of this sometimes, but my main gig is maintaining old Perl/CGI apps, something I've been doing for 7-8 years. Sometimes to maintain my sanity I HAVE to do it differently.

Re:Sounds like a winner...

[yintercept]

I tend to be a database snob, but just about any language that access the database gets its main power from the database. I personally have never seen much difference between accessing a database with Java, C++, PHP, PL/SQL, Visual Basic. Almost all of the programs are dependent on how well you design the database and the code pretty much follows from the relations with in the data.

Java, of course, is the best language because it was developed with an overall higher level of coolness. It has like this oneness with the world thing going on. C++ goes faster. Visual Basic and PHP are easier for beginnning programmers. Still, ti seems to me that relations within the data are the key to database integration happiness.

Application level sequencer == BAD

[wemmick]

...I myself have recently run into the problem of different sequencing systems on different databases (such as MySQL's AUTO_INCREMENT column type vs PostgreSQL's sequence types). I've worked around it by modifying the application's database calls, but that isn't really a good strategy. Implementing a sequencer at the application level (one of the "best practices") is a much better idea...

I disagree. Why do you want to reimplement database features such as sequences when the developers of MySQL, PostgreSQL, Oracle, Sybase, etc. have spent plenty of time optimizing it. Ask Tom Kyte (of Oracle) his opinion about doing something like that -- here's his answer.

"But," you say, "that will mean making different versions of my code for each different database." Not exactly. Take a look at the implementation of Hibernate which uses classes such as OracleDialect and MySQLDialect which are subclasses of Dialect. Each of these specific dialects implements vendor-specific code for sequences (and others). This allows the application level code to maintain its database independence while at the same time taking advantage of the vendor-specific features.

Doug

Junior vs Experienced

[msobkow]

The junior and intermediate developers need "best practices" as a guideline while they learn. The experienced developer knows when to step out of the "best practices" to get performance and features that are needed by the application.

Think of it as driving a car. Most people will never need nor experience the handling of performance car -- the "best practices" of a normal powertrain and suspension are all they need. That doesn't mean there aren't people out there who will make good use of the extra functionality and features.

Re:When is business speak going to die?

[f97tosc]

"Best practices" is common sense for 300$ an hr brought to you by an IBM consultant.

This is true, but many IT departments don't have people with common sense, so this can still be a worthwhile investment. Better, say, than getting new hardware or software based on the IT departments own recommendations.

Tor

Re:"Best Practices"

[smack.addict]

Every language, not just Java, has best practices. In fact, every thing--from using scissors (don't run with them) to playing right field (play to your right when a right-handed batter is at the plate)--has best practices.

And best practices are always evolving. Many past best practices for Java are no longer best practices because Java has changed. Sometimes best practices help you get around a flaw in the underlying tool (like closing result sets and statements in JDBC code). Those best practices eventually become addressed by the tool itself and thus become outdated.

In short, there is nothing wrong with the fact that best practices change. Furthermore, I seriously doubt Sun's marketing department is in any way involved with the concept of best practices.

And finally, if people were really capable of following "best practices" why the hell did Java have to be dumbed down to the lowest common denominator?

As I stated before, a best practice sometimes should be violated. Java cannot and should not enforce every best practice since sometimes you need to violate it. Java tries very hard to choose the right point in the continuum between best practice and "coding law".

Sometimes it may come down on the wrong side by treating some things as best practices that should be law or as treating as law something that should be a best practice. All in all, I think they did a great job even if not close to perfection.

HBUY Practices?

[TheConfusedOne]

Maybe instead of "Best Practices" we can come up with a new term or two:
HBUY (Haven't Blown Up Yet) Practices
WNRSWTW (We're Not Really Sure Why They Work) Practices
DSABAATO (Doesn't Suck As Bad As All The Others) Practices

I think the idea of "Best Practices" really does aim at security, reliability, and robustness. The idea is that someone/some group has found a set of methods that seems to work quite well in regard to these. So, let's use these as the baseline and improve from their instead of creating the same screwups all over again.

Object persistence

[rauhest]

I don't think it is possible to implement a decent persistence framework in C++ that doesn't rely on code generation. Java's reflection API is a big plus here.

I know it for sure because currently I'm working on a C++-based persistence layer -- after spending several months with OJB and Hibernate :)