Slashdot Mirror
Java Database Best Practices
What it's about: The book is divided into three sections of several chapters each:
- Data Architecture - an introduction to database-driven application concepts
- Persistence Fundamentals - descriptions of the various persistence frameworks for Java application development
- Tutorials
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.
Seriously, whenever the question of C++ vs Java comes up in a database environment the C++ in ya just wonders what can be done in Java. This book looks like it will shed some light on what ya should do and the various avenues to explore with databases and java.
Let's all hop on the J-Band Wagon!
--------
Free your mind.
good information about one of the most important aspects of persistance in an object oriented language: Object Relational Mapping. I haven't read the book myself, but if it doesn't cover Java OR mapping layers such as Cocobase, Toplink and EOF (part of WebObjects), or any of the open source OR mapping frameworks, and the theoretical foundation they are all based on, then to me it isn't worth it.
Helping with organizational effectiveness is our job.
How many people out there use java in their web based apps that interface with a database server backend?
What platforms do you use for development?
What Dbs do you use?
What web server?
Why?
Inquiring minds want to check your java intake and output.
ACK
I have never quite figured out why some developers have a visceral negative reaction to the expression "best practices". In any field, a best practice is nothing more than a rule of thumb that guides your decision making. It is a heuristic.
Best practices cannot be fully incorporated into a language. Java does a good job of that, but new best practices grow from further use. As the reviewer noted, the chapters on newer technologies (e.g. JDO) were lighter in this book because programmers simply have not had as much experience in developing best practices with those technologies as with older ones (e.g. JDBC).
Furthermore, a best practice is not something you get sent to the electric chair for violating. When your decision violates a best practice, the "best practice" status simply indicates that you need to understand why it is a best practice and make sure you go to great lengths to justify its violation. On the other hand, you do not need to think a lot about sticking with a best practice.
By leveraging best practices, you simply gain a short-cut in decision-making. For those people who would say "short-cuts in decision making are bad", get real. Short cuts are necessary. You cannot analyze all possibilities resulting from every decision you make. Otherwise, you would never manage to flip a switch to turn on a light bulb.