Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Java Books Media Programming Book Reviews

Java Database Best Practices 180

Posted by timothy from the makes-perfect dept.
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.
This discussion has been archived. No new comments can be posted.

Java Database Best Practices More

Java Database Best Practices

Comments Filter:

  • Sounds like a winner... (Score:4, Interesting)

    by Gortbusters.org ( 637314 ) on Tuesday July 01, 2003 @01:03PM (#6341160) Homepage Journal
    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!
    • My take is that it depends on the app and your goals. C/C++ is generally faster and you get access to more in-depth APIs, at least with Oracle. Java through JDBC is easier to port to different databases and and platforms. JDBC has what I consider to be an advantage in that a lot of database drivers have "thin-client" implementations which means no additional client-side installs. However, almost all the work I've done with JDBC was for server side apps, typically accessing data through app server connection

    • Re:Sounds like a winner... (Score:5, Insightful)

      by yintercept ( 517362 ) on Tuesday July 01, 2003 @02:00PM (#6341812) Homepage Journal
      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.

      • Object persistence (Score:3, Insightful)

        by rauhest ( 560597 )

        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 :)

      • Just about any language can gets its power from a database, but only as long as it's well programmed. Never underestimate the power of sloppy design, sloppy coding, lack of clue, or (my all time favourite) including useless buzzword technologies just because they're the latest hype with clueless managers.

        Yes, if you do a solid database design, and a solid program design which uses said database efficiently, in just about any language you can be as efficient as the database allows you to.

        However, you'd be
      • I bet you'd see a difference if you programmed c/c++ using ODBC to connect to databases using bound parameters. I was talking to a good friend who does Java programming, and he could think of something in Java that was equal to it--especially since Java doesn't have any pointers. Bound parameters speed things up a lot.
    • C++ is dead.

      It went the way of BSD years ago.

      ba-da-dum BANG

  • Looks like they left out the best practice of all:

    Don't use Java.
    • There are many good and valid reasons to use Java, though they don't apply to everyone. For instance, Java is object-orientated which I understand makes code reuse better, I'm guessing because it makes Java plug-n-play. Also, Java has strong datatyping, unlike C, so if you are typing data then you want to use Java. And I think there are Web server modules that let you use Java on a webpage, which improves site usability.

      In short, please try to think before you make rash claims about how lame Java is.

    • Aren't you the same guy who got the bright idea to run two copies of OSX on the new G5s simply because 64bit is "twice as large"? I hardly think you're qualified to be making a statment like "Don't use Java". Besides, I DO use Java and I even sell a database product [datadino.com] based on it. (Keep an eye out over the next week or two for an awesome new version!) And I can say that Java is good for quite a few things *including* database access.

  • hmmm (Score:5, Funny)

    by Anonymous Coward on Tuesday July 01, 2003 @01:06PM (#6341175)

    "...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!

    • Re:hmmm (Score:1, Funny)

      by Anonymous Coward
      huh? I don't know about you, but I'm an expert on Java Databases. Sure, I didn't quite pass the community college intro to programming class, but I've thought about installing gentoo on my eMachines.

    • Re:hmmm (Score:2, Interesting)

      by Anonymous Coward

      There is alot of confusion around proper code practices. A better discussion is taking place on

      theserverside.com [theserverside.com]. Some people are too entrenched to change away from the rdbms centric approach(stored procedures, triggers, etc.). But for the rest of us, I recommend looking into the JCS [apache.org] code which when matched with an OR tool [apache.org], gives the programmer ideal mapping tools. Apache is working slowly on a fine tool called OJB [apache.org] that will hopefully someday include full JDO support. Let them know you're interested. C

  • Transactions/Cursors (Score:5, Informative)

    by Twillerror ( 536681 ) on Tuesday July 01, 2003 @01:09PM (#6341207) Homepage Journal
    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.

    • n-tier applications (Score:3, Insightful)

      by msobkow ( 48369 )

      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 o

      • > Caching them as an array is only viable
        > if the data is stable during your
        > application's execution

        Or you can do an optimistic locking kind of thing... which takes a little more effort, but works well as long as everyone isn't updating the same row.

        > products like PostgreSQL

        +1. Postgres rocks.
    • 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 e
    • Transactions should be short and simple as well. Having a hanging transaction is one of a DBAs worst nightmares.

      I can guess you come from the Sybase world. Come over to Oracle, my friend. Writers do not block readers, readers do not block writers, locks never escalate and deadlocks are automatically detected and resolved. Transactions can therefore be as complex as you want them to be, you can't hurt the database with a bad one.
      • I've been stuck in the depths of DB2 problems that are caused by these exact issues. Hanging transactions, lock escalations, deadlocks resulting in rollbacks or worse yet, timeouts. It's a mess.
      • and deadlocks are automatically detected and resolved.

        Really? And just today i had to kill of an oracle process that was causing a deadlock....

    • 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 does
      • 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.
    • Ask anybody who has done this and they will tell you what a bad idea it is.

      Putting business logic into the database is a tarpit which will doom your application.

      No unit testing, no way to organize your code into discrete files, no compiler to check the sanity of your entire codebase, no object oriented features (for MSSQL anyway), basically crappy SP languages. It goes on and on.

      Having said that most non microsoft databases support java as an SP language and that mitigates a lot of my objections.
  • What's with all the ratings-that-aren't lately?
  • the hell outta cursors with C against an Informix DB. That sucked. ;)
    • Mmmm... tasty, you bring back such fond memories.

      Nothing like plain old C code, with a sprinkling of E-SQL against Infomix SE and Vitamin C ansi libraries for UI handling, all run on SCO 3.2 (and 5.0.5)

      All this to handle dog licenses and deeds for county clerks. Oh the fun!!

      Thank you for making my ordinary day extraordinary! Bleh.
  • 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 hate using framemaker. Poorly-ported Mac software is always the worst. Or maybe I'm thinking of pagemaker. Who cares, it sucks.
      • I hate using framemaker. Poorly-ported Mac software is always the worst. Or maybe I'm thinking of pagemaker. Who cares, it sucks.

        Framemaker was originally developed on Unix.
    • Like all ORA books, this one was typeset using FrameMaker.

      Hmm..FrameMaker is the only program I remember using that rivaled TeX in the flexibility of page layout and quality of the output. Framemaker even accepts EPS for embedded graphics.

      We should just be happy that O'Reilly chose a non-Microsoft application, because a Linux book written in Word, for example, would not only be hideous in appearance but leave OSS users seriously conflicted.
  • It's just coincidence! I read it on Slashdot - [slashdot.org]
    See!

  • Sounds like it is missing... (Score:4, Interesting)

    by under_score ( 65824 ) <mishkin@berteig. c o m> on Tuesday July 01, 2003 @01:20PM (#6341340) Homepage

    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 [thoughtinc.com], Toplink [oracle.com] and EOF (part of WebObjects) [apple.com], 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.

  • Insightful Post (Score:3, Funny)

    by GillBates0 ( 664202 ) on Tuesday July 01, 2003 @01:23PM (#6341380) Homepage Journal
    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.

    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.

  • Ok here is a java question (Score:3, Interesting)

    by ACK!! ( 10229 ) on Tuesday July 01, 2003 @01:27PM (#6341429) Journal
    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.

    • How many people out there use java in their web based apps that interface with a database server backend?

      My teams do

      What platforms do you use for development?

      Windows

      What Dbs do you use?

      MSSQL

      What web server?

      Apache/Tomcat

      Why?

      Because all of our server side programs are written in Java. We deploy to both windows and Linux, Java has increased our productivity over C++, performance is on par with C++ for our systems (sometimes slower, sometimes faster), it means we have one technology for web and progra

    • Re:Ok here is a java question (Score:4, Interesting)

      by pmz ( 462998 ) on Tuesday July 01, 2003 @01:55PM (#6341733) Homepage
      How many people out there use java in their web based apps that interface with a database server backend?

      I would bet that nearly all the use of Java is for web-based apps that interface to a database.

      What platforms do you use for development?

      For Java, it would be J2SE from Sun (it includes JDBC).

      What Dbs do you use?

      Oracle, MySQL, PostgreSQL, DB2, etc.

      What web server?

      Apache, WebLogic, Sun ONE, etc.

      These questions, at face value, mainly answer themselves. Perhaps a better question would be: what do Java programmers do to prevent database applications from turning into a quagmire of naive mistakes and bottlenecks making a well-intentioned application into a sick joke of engineering?

      Database programming is one of those things that is simple enough, at first glance, to be attempted by every college sophomore on the planet, but complex enough, in reality, to make people who hired those college sophomores look foolish.

    • Re:Ok here is a java question (Score:5, Interesting)

      by msobkow ( 48369 ) on Tuesday July 01, 2003 @01:58PM (#6341774) Homepage Journal

      Platform doesn't matter much. Linux, Win32, AIX, Solaris -- they've all got decent Java IDEs and JDKs.

      Databases just need to be full-featured. Sybase, DB/2, Oracle, PostgreSQL -- I don't care as long as it's got a full feature set including sequencers, triggers, and stored procs (in that order of usefulness.)

      Web servers are irrelevant to the back end development. The web server has hooks that redirect certain pages or page types to the "rich" environment of a J2EE or equivalent framework. Even Apache doesn't embed Tomcat, but cooperates with it to share the duties (let Apache do what it does best -- server up simple content, and let Tomcat/J2EE/JSP do what it does best -- serve up functionality with a corresponding performance hit.)

    • Personally, I've found that Tomcat, with an Apache bridge, on a Linux box, though we still have Sun's floating around, and Oracle does a bang up job. Oracle isn't my personal favorite, but we're doing well with this setup. Heavy use of stored procedures, makes the middle tier code generally short and sweet and a JSP front end makes for quick GUI building. Of course YMMV.
      • Oracle isn't my personal favorite, but we're doing well with this setup.

        Try DB2, you'll be loving Oracle in no time.

        Unless you can try a MySQL or PostGRES, I don't know much about either, but have heard good things about them both.

    • I'm using Java for a data warehouse web app (which is somewhat different from the usual database app, because there aren't significant amounts of data going in through the application). We develop on Linux and Windows and will deploy on Linux. We're using Oracle and Tomcat.

      We're using Java mainly because we used it for a previous project and it worked well; switching to a different language, including evaluating, leaning, and determining good practices would not be worthwhile. We're using Oracle and Tomcat
    • I do.

      JBuilder, and now increasingly Eclipse.

      Oracle.

      WebSphere.

      Because that's what the company has bought.

    • What platforms do you use for development?

      NetBeans hooked into a CVS server. It offers a huge amount of functionality (nearly competitive with JBuilder) and it is free.

      What Dbs do you use?

      Oracle 8i, although we're migrating to Oracle 9 fairly shortly. High-availability, clustering, and reliability. Oracle cannot be beaten.

      What web server?

      Apache 2.0 in "worker" MPM mode. Multi-threaded, multi-process. Provides the stability of Apache 1.3 (multi-process so if one process crashes, no problem, t

      • Provides the stability of Apache 1.3 (multi-process so if one process crashes, no problem, they just get started right back up) along with a huge speed increase due to the multithreading.

        Are you running Apache on Windows?

        I'm not aware of any other platforms that gain much from multithreading. Though possibly NPTL on Linux will change that (but surely you aren't running the 2.5 kernel).
        • Solaris.

          The problem with Apache 1.3 is that each connection requires a separate instance of the child process, which in turn takes up 2 megs (or so) of memory. Multiply that by 500 concurrent clients, and you see the bottleneck right there.

          With 2.0 in MPM mode, each process (which we have configured to take 250 threads/children) takes up about 30-40 megs of memory. 500 concurrent clients takes up 80 megs of memory, as opposed to the 1 gig of memory with Apache 1.3.

          So the issue isn't that multithread

      • Apache 2.0 in "worker" MPM mode. Multi-threaded, multi-process. Provides the stability of Apache 1.3 (multi-process so if one process crashes, no problem, they just get started right back up) along with a huge speed increase due to the multithreading. Changing from Apache 1.3 to Apache 2.0 in worker mode, tuned correctly, will give you a 500% capacity and speed boost, easily. We have gone from approximately 85 simultaneous connections max, running at about 200 requests per second, to over 2500 simultaneous

        • Just curious - does performance of Apache really matter, i.e. wouldn't you reach the capacity of your app server (Resin in this case) way before you reach any limit of Apache?

          Nope. Think about this-- say you have a page that is made up of:

          - 1 JSP page
          - 1 CSS file
          - 1 JS file
          - 7 images

          90% of your content is static, and can therefore be served up by Apache. Even by limiting Resin's threads to 250 simultaneous, you can safely set Apache up to handle 2500 concurrent requests, realizing that 90% of tho

    • several projects over last 5 years:

      os/web server/application server/database

      Linux/Apache/Oracle AS( piece of shit) / Oracle
      NT/IIS/Tomcat/SQL Server
      NT/IIS/Web Logic/SQL Server
      Linux/Apache/Web Logic/Oracle
      Solaris/Apache/Oracle AS/Oracle
    • How many people out there use java in their web based apps that interface with a database server backend?

      Almost everyone.

      What platforms do you use for development?

      Eclipse, Websphere Studio Application Developer

      What Dbs do you use?

      SQL Server 2000

      What web server?

      Apache/Tomcat/JBoss

      Why?

      Because they're all any 2 of the following 3:

      a) Free
      b) Easy to use/configure
      c) Powerful

      Actually, Websphere is only (c), but meh...

    • No Java.NET adopters? :-P

      ducks...

  • 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.

    • Re:"Best Practices" (Score:5, Interesting)

      by smack.addict ( 116174 ) on Tuesday July 01, 2003 @01:46PM (#6341640)
      Disclaimer: I am the author of the book being reviewed.

      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.

      • 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 th
        • I think the greater problem with hearing "best practices" from the Java crowd is that they keep changing them.

          Also, a lot of these "best prctices" are pushed out by Sun's marketing well before any sort of performance is up to par.

          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? If we assume people can code to "best practices" then Java would never have come about. That's its chief selling point, you ca
          • 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 eventua

      • "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. "

        Developers are allergic to the expression, not to the concept. Call it "design patterns" next time and you'll have them all worshipping at your feet.
      • smack.addict said:
        Disclaimer: I am the author of the book being reviewed.
        I bet you would sell more copies of your book if it indicated on the cover "by smack.addict" instead of the more innocent and questionable "George Reese". And instead of that fat hairy cat (wtf is that thing anyway?), you should have had a pic of a spoon with a lighter under it.

    • Junior vs Experienced (Score:3, Insightful)

      by msobkow ( 48369 )

      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 fu

      • OK, fair enough - so why do some books and classes for beginners teach outside of the best practices?
        • probably because that's what the authors are learning, and that's the hot topics. 8 years ago, c++ classes were teaching how to code all types of lists. i guess because that's what people did a lot. that or so the people who used the lists had some notion of what a list is and what it does.

          the only reason that someone today would write a list class in java or in c++ or any other oo language is that they _really_ need something specific or they don't understand the power of using tested code. it generall
    • ... why the hell don't they just constrain the language ...

      Because when language developers constrain the language to what they want users (application developers) to do, you wind up with something like dBase II; primitive, non-extensible, and extremely frustrating.

  • Clustering and Sequences (Score:5, Informative)

    by smack.addict ( 116174 ) on Tuesday July 01, 2003 @01:53PM (#6341703)
    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.

    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.

  • Application level sequencer == BAD (Score:5, Insightful)

    by wemmick ( 22057 ) on Tuesday July 01, 2003 @02:01PM (#6341817) Journal
    ...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 [oracle.com].

    "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 [sourceforge.net] 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

    • Application sequencers are the correct approach. You use as the only supporting evidence behind your claim that "Application level sequence == BAD":

      Ask Tom Kyte (of Oracle) his opinion about doing something like that

      In that article, Tom talks about a specific kind of application-level sequencer. The sequence he talks about is, in fact, a bad sequencer. When implementing an application-level sequencer, you must take into account the following:

      • Generated IDs must be guaranteed to be unique.
      • The act of
    • That page gave an example of a bad way to do it. There are also good ways to do it. I'm sure there are many implementations of things similar to my GetPK [spy.net].

      This provides application level sequences in a cluster and bypasses a lot of performance issues. Combined with my hierarchial storage model, it allows us to build out large complex trees of objects where the objects all know the primary keys of all of the objects as they will be if they get stored in the DB. The framework also allows us to ensure the

  • 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

    • Holy cow, but you have done a lot of development work to duplicate existing efforts.

      To give you an idea, in NetBeans/SunONE/JBuilder/etc, you model your database (or import the schema from an existing JDBC connection) and then right-click on the table you're looking to create a bean for, select (something like) "Generate Classes" and poof, the IDE does all your work for you.

  • 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?
  • 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
  • I read the chapter that was available on the website in PDF form and best practive my a**!

    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 :bindvariable and assign WHATEVER to :bindvariable
    • Except the example chapter is about database architecture and not database programming. And it comes in the book before I have introduced the concept of bind variables (aka callable statements) or stored procedures. Thus, it is:

      a) Not a best practice in database architecture, so inappropriate to call out as a best practice at that point
      b) Too complex a concept to assume knowledge of at that point in the book

      As a side note, I do call this out as a best practice in a later chapter and all subsequent chap

  • It might just be me having a bad day, but a usual I react with a vaulting wave of sheer loathing upon hearing the phrase "Best Practices". Desensitized? Try Over-Sensitized!

    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

Slashdot Top Deals

"An idealist is one who, on noticing that a rose smells better than a cabbage, concludes that it will also make better soup." - H.L. Mencken

Close