This week's book giveaway is in the Agile and other Processes forum. We're giving away four copies of The Mikado Method and have Ola Ellnestam and Daniel Brolund on-line! See this thread for details.
I know that JDBC basically allows you to ignore the specific database. but do you guys know any really interesting books about Java and SQL Server specifically.
In fact, any books on the topic would be welcome.
[ February 04, 2006: Message edited by: Brandon Tom ] [ February 04, 2006: Message edited by: Brandon Tom ]
Brandon Tom, SCJP, MCP<br />Programmer/Graphic Designer<br /><a href="http://mailto:tombrand@hawaii.edu" target="_blank" rel="nofollow">tombrand@hawaii.edu</a>
Michael Duffy
Ranch Hand
Joined: Oct 15, 2005
Posts: 163
posted
0
Originally posted by Brandon Tom: I know that JDBC basically allows you to ignore the specific database. but do you guys know any really interesting books about Java and SQL Server specifically.
In fact, any books on the topic would be welcome.
[ February 04, 2006: Message edited by: Brandon Tom ]
[ February 04, 2006: Message edited by: Brandon Tom ]
I'm sure you won't find any.
Lots of books about JDBC, more about SQL Server, but I'll bet none about the two topics together.
As you've said, JDBC abstracts you from the database vendor. The success of that notion is borne out by the fact that there ARE no books on it.
There are books on some common databases and JDBC. I just read one on Oracle. But I haven't seen it for any other databases. That's not to say they don't exist, of course.
Maybe another approach is to try searching for SQL Server on Amazon and seeing if anyone has read them?
Originally posted by Brandon Tom: I know that JDBC basically allows you to ignore the specific database.
Sadly, that's not nearly as true as anyone would like. While there's a very very large "common denominator" among the major DBs when using JDBC, there's still a huge amount of DB-specific stuff that intermediate-to-advanced developers get into.
A quick casual example is the vendor default behavior when Statement.setFetchSize() hasn't been called. Some vendor's drivers will by default will fetch a single row at a time, thereby creating an I/O bottleneck; some drivers will fetch all returned rows in the ResultSet, thereby creating a scaling problem with large results (running you out of memory, typically), and some drivers have default fetch sizes that avoid these extremes, but may still not be right for your situation.