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.
why do i need a database for COFFEE?
what's with all the COFFEE books?
this sig limit is too small to put anything good h
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.
Looks like they left out the best practice of all:
Don't use Java.
Boromir, son of Faramir, King of Gondor and Minas Tirith
"...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!
"Best Practices" is yet another ridiculous business term that is crossing over into the IT world. It means nothing. Just like Stallman ripped on the term "Intellectual Property" last week, I will say that "Best Practices" is a term used to impress idiot suits. Just like IP, it covers a wide array of topics without giving any of them sufficient attention. Who needs this? Probably the suits who need to be fed pablum because they don't grok tech. But this word is generally useless for a majority of the world. Every time I see it used, I wnt to punch someone. Don't talk about "Best Practices", talk about the real issues: Security, Reliability, Robustness. When you talk about Best Practices, it makes you sound like a marketroid drone or yet another clueless, retarded suit.
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.
What's with all the ratings-that-aren't lately?
TODO: Something witty here...
the hell outta cursors with C against an Informix DB. That sucked. ;)
In short, please try to think before you make rash claims about how lame Java is. It might be too hard for your mother to use, but other people see that as merely being powerful.
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.
Having a hanging transaction is one of a DBAs worst nightmares.
So, DBAs don't have a whole lot to worry about in this world, eh? If that's your worst nightmare, you should consider yourself a very luck man.
It's just coincidence! I read it on Slashdot -
See!
Valete!
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
Your post was so stupid that it got modded troll!
so if you are typing data then you want to use Java
that let you use Java on a webpage
retard
But google cache also caches pdf files, and you can read the google version without a pdf viewer
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
If there are these "Best Practices" that are endorsed by the language makers, then why the hell don't they just constrain the language to only allow you to program in the "best practice" way? I mean, why allow you to screw up and use "worst practices" when they already know the best way? It seems like a setup to me.
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.
This place needs more rational arguments like yours and less knee-jerk reactions like the parent post. Moderators, please don't let this gem slip under your radar.
I agree, they need more coverage on ODBMS, especially since ODBMS will replace the legacy RDBMS by 1999.
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.
I was going to just mod you down, but I couldn't find the "crazy" mod.
In years of working with databases (mostly Oracle) I've yet to have a problem with Java, locking, and transaction control.
What can happen is you forget to close a connection - but that's just poor coding. Going though the relatively extreme agony of defining a bunch of stored procedures instead of making people using "finally()" for close statements just makes no sense - at least for Java. The JDBC API is very mature, and as someone else noted it's not the library doing the actual locking or transaction work, it's the DB (at least for Oracle, perhaps other drivers do things differently when your database does not support locking(?!).
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
I'm currently working on an article about an easy way to generate all the base classes you need for persistence. It's a lot of repetitative work to build that interface layer between SQL and target language.
The basic idea is that one converts SQL into XML, then applies and XSLT to generate all the base classes. I've applied this idea to three projects now, and I've gotten to where the autogenerator handles things like intersects properly.
So if you get it right in the XSL, one can change the SQL structure of the tables and the code can stay updated automatically. Find a bug in the persistence code, fix it in one place. Voila it propagates to all instances. A serious timesaver this is.
Just thought I'd throw this in for those interested in this topic. Consider it like an ice-cream topping.
I used to wonder what was so holy about a silent night, now I have a child.
So someone expresses several perfectly valid points - and a Troll?
/. is getting shallower everyday
Thanks poster, glad to see some real-life enterprise coders out there.
Pseudo off-topic --
I should learn how to write stored proceedures. Any book recommendations out there?
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'm somewhat interested in what SQL books people would recommend. At this point I'm proficient in SQL, but there are a lot of people that I'd like to make recommendations to. The problem is that I learned SQL on the internet and really have no idea which books are good and which aren't. Any good recommendations?
Javascript + Nintendo DSi = DSiCade
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 :)
Seems pretty thin on the content. With a book about persistence I'd expect at least quick introductions to OJB's, Hibernate, iBatis, JISP, Prevayler, etc...
Daniel
Carpe Diem
How long does it take to get new O'Reilly books on Safari?
I am sick and tired of books warning me that if i do a certain thing in a certain way, i will be tied down to a database. How many projects switch from Oracle to sybase? How many project managers expect the switch, if it is carried out, will be without any changes to the code? books on best practices and performance are good but some of the best practices evolve over time. What may be a critical performance bottleneck now may not be a problem in a few years. I am sure there was a performance "tip" at one time that recommended using 2 characters for storing the year to save on memory.
What does SCO stand for?
I read the chapter that was available on the website in PDF form and best practive my a**!
:bindvariable and assign WHATEVER to :bindvariable, you will only have to parse the statement once and whenever someone enters a different search criteria, i.e WHATNOT instead of WHATEVER, the database will not have to consider the select statement as a new and unique statement but use the one already pre-parsed in memory and only substitue the bindvariable with the actual value.
When you talk about best practice, you could at least mention the best of them all, esp with databases like Oracle, use of bindvariables.
The book gives examples in the form of:
select blah from tableblah where bleh='WHATEVER';
Everyone with some experience from an enterprise database knows the rule is: "Parse once, execute many times". By replacing 'WHATEVER' with
Now, that's best practice!
If the rest of the book is as sloppy, then stay away from it.
If you mod me down, I *will* introduce you to my sister!
One other advantage of stored procedures is that they are easier to deploy in a production environment since a server restart is usually not required. However I dislike using stored procedures (in Oracle, anyway) for several practical reasons:
1. The syntax for stored procedures is awful. I always wondered where the hell they stole their syntax until I finally ran across some COBOL.
2. The compiler and runtime error checking are poor. The compiler generally stops at the first error it sees, and it doesn't always report the line number correctly. And you practically have to be a DBA to figure out some of the problems that can occur with procedures.
3. Code maintenance is a hassle. All of our other sources are easily compared to their deployments using basic file commands in the OS. However SQL commands must be used to verify the source in our Oracle DB. And Oracle reformats our procedures even if they compile properly, which means the source cannot be compared to the target anyway.
At my company we adhere to such a methodology and have delivered software that eventually compiled - every time.
With that, I'd like to introduce our unified methodology and propose that it be given proper respect through widespread implementation.
SOP - Seat Of Pants
You don't even want to know where I work...
Computer Science is Applied Philosophy
Maybe that's just because I learned to use Oracle PL/SQL first and had to learn Transact SQL at my subsequent jobs. I still prefer PL/SQL. Hell it makes me look better too when our parent company needs help extracting data for our office and they can call me to write them a stored procedure and the other developers cannot (they also call me for linux/solaris help and we *technically* are a MS only shop).
At least my CIO doesn't have his head up his ass like the rest of the C*Os do.
JAVA ??? R.I.P. !! .. GONE !
Its going , going , going
(You have also been trolled)
YHL
HAND
In my experience the only people who use such terms are mediocre Sales & Marketing managers who are supreme bullshitters and such phrases are the way they get this bullshit propogated. Then since they really do not have a clue about things like security, reliability, robustness, risk management, or engineering, nor real success at their own field, they use such terms to get software engineers to defend their decisions ad nauseum.
You are not going to get an entry-level scripter to become a master programmer by getting him to read a book on "Best Practices", you will not save time, money, or personnel, and you will alienate the true professionals on the team. But, you will be able to attempt closing a large account by using these buzzwords.
Certainly it is important to base operations on objective reality but this is not the way. What constitutes the best practice must by definition change with time, business requirements, team abilities, and so on. You need not a blind committment to a list of best practices, you need rather a cadre of live human beings who are capable of making a decision about what practice (we call that operational strategy in the real world) will be appropriate. The client is most likely not able to make this decision, they are depending on you to do it and usually want to believe that you have a sincere philosophy based on doing a good job and making them happy.
In particular "Best Practices" like I suppose J2EE, Weblogic, Oracle, or Sun are usually death to most web-based midsize projects in this economic environment, if the same result can be accomplished with more speed, safety, and cost performance using systems like perl/jsp, mysql/postgres, bsd/linux. Although perhaps J2EE has gotten more economical, if so I've missed it for the past year. The times you really need the high-power products are not going to be discovered with a beginners' book like this one. Although it might be useful for independent developers to read and understand the Language of the Enemy (LotE). It can help you eat their lunch.
Of course, I haven't read the book and I ought to give them the benefit of the doubt, after all I like O'Reilly a lot. Luckily this book sounds too technical for marketing types so it is probably not a valid target for accusations of pandering. It sounds like there is a lot of good information in there, and the "best practices" term is from the reviewer (after all, who wants to be against "best practices"?) Usually when I hear the term it means anathema to explaining clearly and concisely what kinds of knowledge, decision-making talents, experience, policies and operations are going to promote reliability/security/robustness. Personally, if I must use market speak (almost never I think unless competing against someone who does) I will qualify each word carefully so as to help the client understand that it is about professionalism and committment, not about a power sales technique. Of course if they don't want to think about it I'll still do my best but when somebody else comes along they will have only themselves to blame! Well no point in ranting perhaps.
Terms like "Best Practices" are still around because some people don't want to think seriously about IT, and those who are serious do not have the conceptual tools to do so. This gives cynical managers tools to leverage fear and uncertainty.
Where I come from, the best practice is to work very hard at doing The Right Thing but to also consider what the right technical strategy is on a case by case basis, in order to deliver the best cost efficiency and performance. In other words, think about the customer. They want to trust you that you know your business and will do a professional job. They do not (unless they are gullible, which explains a lot about this industry) want to hear buzzwords from marketdroids who
The database access in Java is really a mess. On one side we have the EJB technology, now grown up and mature, but still having many problems: you cannot use built-in database sequences, instead you have to resort yourself to the well known hack (in the Java Community a hack is called "the pattern") with session bean and entity bean. Reading from database is rather slow - you have to use DAO (write them by hand or have generated like in OptimalJ) or resort to container specific practices - like in JBoss - where you define how many rows should be read at a time.
Even more mess is due to arrival of the new technologies duplicating the functionality of the EJB - like the JDO, which (as I have read in: JBoss chooses the JDO) may be the basis of enterprise Java in tommorow meaning not only the betterment of your applications but also meaning that new sources of incopatibility will emerge.
In this case one fears that his applications will have to be rewritten, the tools will change, the practices you learn now will become obsolete.
Additionally there is still the problem of using the database effectively. The more indirection you have in accessing the DBMS, the more portability you acquire, the less specific you can be. Those questions need answer if the Java Enterprise Technology shall continue to lead.
You can defy gravity... for a short time
+5, Funny!
Well, my goal is to be perceived as a database programming guru. I already store XML in the data...but you bring up a good question: Exactly how do you change the color of the scroll bar...
I mean, if some young buck has a database that changes the color of the scroll bar, I know I am toast. Are there any good acronyms involved in the field of SBCT (ScollBar Changing Technologies)?
Transaction commit and rollback are an integral part of databases. Without it, you've just got a keyed file structure, not a database.
I did, however, forget to mention integrity checking, which is even more useful than sequencers.
I do not fail; I succeed at finding out what does not work.