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.
"...I do not consider myself to be an expert on the subject."
Well then, you should fit in perfectly with the rest of the Slashbots!
I always had a problem with APIs doing locking and transaction control.
If your application really requires these things, you might want to get a database server that has direct support for them and write them as stored procedures. Straight SQL stored procedures can be very powerful, and can keep a lot of this messy logic where it belongs on the database server. Transactions should be short and simple as well.
Having a hanging transaction is one of a DBAs worst nightmares.
I think for the most part client/server applications are loosing ground to more of a three tier application scheme. In this case the cursor or the scrollable result set should be dumped, and instead just scroll through once and dump into a two dimensional array and access them this way. Grab and go.
Like all ORA books, this one was typeset using FrameMaker. FrameMaker! I urge you to boycott ORA until they come to their senses and use TeX to produce high-quality typesetting.
I think programmers get desensetized (spelling?) to some sorts of phrases, and some of us miss out because of it. Best Practices are actually a Good Thing(tm). They are what separates professional Software Engineers from most coders who don't have a clue about system design, and aren't interested in learning. There are some good books in this area, although the primary one escapes me now...
Most writers regard truth as their most valuable possession, and therefore are most economical in its use - Mark Twain
"Best practices" is common sense for 300$ an hr brought to you by an IBM consultant.
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.
I was excited to read this title when I first noticed it listed on the Slashdot site soon after lunch. I downloaded and read the first couple paragraphs and waited expectantly for the material to seep through. I was hoping that this article would be perfect for me to post an insightful reply on as nearly all of morning, I have been feeling dull and stupid. though I am usually not so.
Anyway, I don't think it's working. I give up.
An Indian-American Hindu committed to non-violent thought/speech/action alarmed by the global explosion of radical Islam
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
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.
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.
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.
I do not fail; I succeed at finding out what does not work.
Actually, with some slight transactional modifications, it can be used in a clustered environment as designed. It was, in fact, originally designed to support a clustered pre-EJB application. I made the transaction support for the sake of this book simpler to illustrate the point.
The key to this scheme is that each application gets its own sequence key, so multiple applications or cluster nodes are free to generate unique IDs without duplication by other nodes or applications.
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.
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
___
Cognitive Overflow
more than yo
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.
I do not fail; I succeed at finding out what does not work.
"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
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.
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.
--- I wish I could hear the soundtrack to my life. That way I'd know when to duck.
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 :)