my dog learned polymorphism*
The moose likes JDBC and the fly likes Usage of JDBC in the IT industry Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC
Bookmark "Usage of JDBC in the IT industry" Watch "Usage of JDBC in the IT industry" New topic
Author

Usage of JDBC in the IT industry

palla sridhar
Ranch Hand

Joined: Oct 15, 2007
Posts: 111
I would like to know how much JDBC is being used my companies, when everyone is moving towards Hibernate and Spring. Is there any advantage in using JDBC still or its over-taken by any other technologies, as i hear more people saying that JDBC is outdated..

Please enlighten me on this issue..

Sridhar Palla


Thanks and Regards,
[url]www.techlikes.com[/url]
*Nothing is CONSTANT in life, except CHANGE*
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41600
    
  55
Welcome to JavaRanch.

On your way in you may have missed that we have a policy on screen names here at JavaRanch. Basically, it must consist of a first name, a space, and a last name, and not be obviously fictitious. Since yours does not conform with it, please take a moment to change it, which you can do right here.

As to your question, Hibernate and other ORM frameworks are built on top of JDBC, so it continues to be important. I've also found that raw JDBC performs significantly better in situations where the objects generated by ORM frameworks aren't required, e.g. when importing large amounts of data into a DB.


Ping & DNS - my free Android networking tools app
Jan Cumps
Bartender

Joined: Dec 20, 2006
Posts: 2497
    
    8

We're still using jdbc a lot.
And the off-the-shelf products we buy (integration servers, erp software, content management platforms) too. Some directly, others with springs, hybernates or others.
But the larger half use jdbc directly.

Regards, Jan


OCUP UML fundamental and ITIL foundation
youtube channel
Pavel Kubal
Ranch Hand

Joined: Mar 13, 2004
Posts: 356
Hi Sridhar, for past 3 years I've been on several projects and still a significant percentage used pure JDBC for database layer. On the other hand, the world tends to use ORM instead of JDBC, but there remains a lot of systems based on the obsolete way of accessing database and you never know if don't get this project to bug fix or maintenance. Whatsmore, JDBC is not so hard to learn and we teach every single java developer at least basics of JDBC, because it is totally worth understanding JDBC exceptions and the way how JDBC works.

So the conclusion is, you don't need to be an expert on JDBC, but it is worth to know.
Charles McGuire
Ranch Hand

Joined: Jan 18, 2005
Posts: 99
It's interesting, but most of my applications work fine going right to the data with JDBC. Performance is better as my SQL statements are finely structured to retrieve exactly what I want. There isn't a huge ORM layer in between that has to inflate data objects.

I also know that what I get out of the data base is real. It's current. Constraints and validations are defined to the DB, so I don't have to worry about something bypassing the ORM validations with a tool outside of the application. Data integrity is very high.

The HF book is about basic SQL, but I'd be interested in a book or well written article that talks about leveraging JDBC (and SQL) in applications instead of surrendering to application bloat via ORM and all the fragility that comes with it.


There's no place like 127.0.0.1
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61092
    
  66

Originally posted by Charles McGuire:
but I'd be interested in a book or well written article that talks about leveraging JDBC (and SQL) in applications instead of surrendering to application bloat via ORM and all the fragility that comes with it.

As would I. At least it's nice to know that there's at least one other person who doesn't think that letting some bloated framework do all your thinking isn't a maverick approach.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Ulf Dittmer
Marshal

Joined: Mar 22, 2005
Posts: 41600
    
  55
Originally posted by Charles McGuire:
Performance is better as my SQL statements are finely structured to retrieve exactly what I want. There isn't a huge ORM layer in between that has to inflate data objects.

Assuming that you're talking about retrieving complete rows when only a subset is needed, then that's not what ORMs generally do (maybe some do). A query that specifies a subset will retrieve a subset, not more. And no row-wrapping objects will be created, either.

Constraints and validations are defined to the DB, so I don't have to worry about something bypassing the ORM validations with a tool outside of the application. Data integrity is very high.

Using an ORM doesn't change any of this. Some applications choose to manage constraints and validations in the DB; some choose to do it in the DB. I'm not sure how using an ORM -which is free to do or not do these things- makes a difference in this regard.

application bloat via ORM and all the fragility that comes with it.
Can you explain what you mean by fragility? What kinds of scenarios do you have to guard against when using an ORM that you didn't without one?
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Usage of JDBC in the IT industry