|
I confess that I didn't start reading this thread until the last couple posts. Sorry... very busy. Please accept my apologies if I simple re-interate some of the points made earlier. I thought some of you might want my take on the issue from sitting 'behind the wall'. Eric, I do not choose to debate you, I simply disagree.... here is my rationale: 1) Performance: I would be skeptical that you can complete many tasks 10 to 15 times faster using record level access through Java than I can complete them using JDBC. You may want to investigate various object caching issues though JDBC. In the majority of application spaces that I have seen, you can use effective object caching to limit the database overhead of using SQL. 2) Simplicity: We have a group internally working on the TPC-W benchmark. They have been working on it for months and the performance tuning of it is quite complex. Myself and another member of my team wrote the vast majority of the same benchmark using Java/JDBC in about a week or so. We built a couple database indexes, used *very* smart caching of JDBC objects and had the implementation ready to go out the door. Yes, we did it in about a week. When they are done, will they beat us in performance? Yes, they will. But with tuning we will approach their numbers. Their initial estimate was that a Java based solution would be 7-40 times slower. We expect to be within 2x. Now, ask youself this: which version is more likely to have bugs in it? Which version do you want to maintain and modify in the future? 3) Future: The future is SQL. This is not an opinion of mine, this is fact. Everyone continuously screams for standardization of Java, standardization in XML, etc.... yet so many people are so quick to defend the proprietary when that is what they know. SQL is a stardard and it will clearly define future direction. It will clearly be where the (vast) majority of our effort is invested. Make sure that you are prepared for that. As you mentioned, your encapsulation of database access should allow for that, but I don't think you will be switching to use JDBC when it is faster. For many tasks, it will never be faster. You will be switching because you will not have features you need through Native IO. There, I have said my piece. Choose your directions. If you are familiar enough with Native IO to be efficient with it and convinced your future is safe through Native IO. You should use it. If you choose to, you should make sure you have provided youself the correct encapsulation to move away from that path in the future if you need to. If you choose the SQL/JDBC path, you probably don't need that encapsulation... you won't be going back. Regards, Richard D. Dettinger AS/400 Java Data Access Team "TRUE! nervous, very, very dreadfully nervous I had been and am; but why WILL you say that I am mad? The disease had sharpened my senses, not destroyed, not dulled them. " - Edgar Allan Poe "The Tell-Tale Heart" +--- | This is the JAVA/400 Mailing List! | To submit a new message, send your mail to JAVA400-L@midrange.com. | To subscribe to this list send email to JAVA400-L-SUB@midrange.com. | To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com. | Questions should be directed to the list owner: joe@zappie.net +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.