[login to unmask email] - Email found in subject - Re: [DB2-L] Building applications

Ian Davies

[login to unmask email] - Email found in subject - Re: [DB2-L] Building applications
Hi Brad,

Going with what Joel said, we have to support a number of applications that use Hibernate and it makes for some interesting tuning exercises. The SQL it generates might work moderately well in a development environment but, in our experience, does not scale well. The best thing about hand coded DML is that it can be kept simple and simple SQL is pretty damn portable these days and pretty efficient, even if you forego the idiosyncrasies.

Other than the performance impact the use of Hibernate seems to de-skill the developers such that they do not understand the data as well as they should and finally, my biggest peeve, I keep getting asked by the developers to change the data model to make the product easier to work with, OIDs anyone?

Cheers,
Ian.

________________________________

From: DB2 Data Base Discussion List [mailto:[login to unmask email] On Behalf Of Joel Goldstein - Responsive Systems
Sent: September 20, 2006 09:11
To: [login to unmask email]
Subject: [DB2-L] [login to unmask email] - Email found in subject - Re: [DB2-L] Building applications for DBMS independence


Sure, this can be done - with performance penalties.
Maybe 10% maybe a couple of hundred %.

Every dbms has its' idiosyncrasies - exploiting them improves your performance, on THAT dbms.
That same exploitation will probably hurt you on the next dbms.

The last thing you want to consider is any kind of a black box interface to handle your
database access. That's a guaranteed path to performance disaster.

Regards,
Joel


Joel Goldstein
Responsive Systems
Buffer Pool Tool for DB2, the worldwide industry standard
Performance software that works......
Predicts Group Buffer Pool performance too!
www.responsivesystems.com
(732) 972-1261

----- Original Message -----
From: Dave Nance <mailto:[login to unmask email]>
Newsgroups: bit.listserv.db2-l
To: [login to unmask email]
Sent: Wednesday, September 20, 2006 10:54 AM
Subject: Re: [DB2-L] Building applications for DBMS independence

Brad,
One of the thoughts would be hibernate. We are currently investigating using this open source product as our persistence layer, www.hibernate.org . We have not as yet made the decision to go this route and are in just early stages of research.

Dave Nance


"Brad E. Melton" <[login to unmask email]> wrote:

DB2-L,

I'm investigating ways to develop applications that are database vendor
independent. I believe it would be advantageous to be able to rapidly
swap database vendors as other vendor solutions become more desirable.

For example, several on this list have suffered through DBMS conversions.
Converting to/from DB2 for z/OS, UDB, Oracle, SQLServer, etc. can be a
challenge. I know there are DBMS conversion tools but such tools are
additional cost and only go so far. What if we could build our
applications so that we could drop one DBMS for another with minimal
effort?

Like many of you, my career spans a couple decades and most of it has been
in mainframe and DB2 land. DB2 will always hold a special place in my
heart and I believe that in many cases DB2 for z/OS can be the best
alternative. However, if we are honest with ourselves I believe we'll
agree that it is not in a database customer's best interest to remain
biased toward one vendor or the other. It is in our best interest to
accomplish our goals with the least cost. The ability to easily swap DBMS
products would be a great advantage during contract negotiation.

Can someone share their experience with developing DBMS independent
applications? Did it pay off? Did you experience a quick and painless
conversion? Did it help you negotiate a more favorable vendor price?

Also, if you've suffered through a DBMS conversion, whether to or from DB2
or any other DBMS, please share your challenges that made the conversion
difficult. What could have been done differently in the applications or
infrastructure that would have provided a smoother conversion?

Here are some of my thoughts:

* Do not use SQL syntax specific to any DBMS.
* Do not use stored procedures. Vendors implement them their own way and
many do not easily convert.
* Choose coding and connectivity standards that are universal to all
relational database management systems. For example, web based, JDBC.
* Choose monitoring tools and/or build your own that are universal to all
DBMS.
* Implement change control governance that enforces these standards.
* People fear change -especially when it involves their chosen career.
Eliminate adversaries and turn them into advocates by getting everyone
(Development, DBA, DBE) involved and working toward the goal.

Thanks for your thoughts,
Brad

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm




________________________________

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. --------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm <http://us.rd.yahoo.com/mail_us/taglines/postman7/*http://us.rd.yahoo.com/evt=39666/* http://messenger.yahoo.com >

--------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm --------------------------------------------------------------------------------- Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm

---------------------------------------------------------------------------------
Welcome to the IDUG DB2-L list. To unsubscribe, go to the archives and home page at http://www.idugdb2-l.org/archives/db2-l.html. From that page select "Join or Leave the list". The IDUG DB2-L FAQ is at http://www.idugdb2-l.org. The IDUG List Admins can be reached at [login to unmask email] Find out the latest on IDUG conferences at http://conferences.idug.org/index.cfm