• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

iBATIS: Database Independance

 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi again,

We are just staring a large multi-year project and will likely be using 2 databases: Oracle and KDB+ (a time series database that supports JDBC). KDB+ will be running on an Solid State Device for ultimate performance and (unfortunately) high cost.

At this time, we aren't sure which tables will reside in KDB and which will reside in Oracle (it will be a matter of benchmarking) so having objects that are DB independant would be important.

Other than 'if' statements to check which database an object comes from, how will this work with iBATIS?

Thanks,

David
 
author
Posts: 21
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
iBATIS won't make your situation any better or worse, and I don't believe Hibernate or any other ORM would either.

Nothing will magically solve the challenge you have before you. One thing I can say for iBATIS is this:

* iBATIS doesn't assume a single data source for your data. Therefore it doesn't complicate environments with two or ten databases (most enterprise databases I've worked on are in fact multiple databases).

* SQL can be written in a portable fashion. JPetStore 1.0 ran on 11 different databases without a single code change.

* However, when you do need a special function or feature of your database, you can do it very easily. I think if you're using two databases, there be some reason and therefore I predict some proprietary database feature use in your future.

* iBATIS also allows you to map the same class to multiple database models/instances...something Hibernate and TopLink would take issue with.

Those are a few that I can think of right now...

Hope that helps.

Clinton
 
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I also believe that this is best handled at a slightly higher level than iBATIS operates at. I've handled this in the past (in web apps using straight JDBC) by use of a "plug-in" architecture based upon interfaces. Not an "if" in sight!

A "switch" (usually a context variable in my deployment descriptor) defines which database is to be used, and the appropriate classes that implement the plug-in interfaces are loaded to handle all database-specific activities.
 
Bear Bibeault
Sheriff
Posts: 67746
173
Mac Mac OS X IntelliJ IDE jQuery TypeScript Java iOS
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
P.S. Other than avoidance of "ifs", another advantage of the above scheme is that new databases can be supported without having to change and recompile any code other than the new database support classes. Just drop them into the classpath and it's good to go!
reply
    Bookmark Topic Watch Topic
  • New Topic