Re: Java to die in 2003

From: Galen Boyer <galenboyer_at_hotpop.com>
Date: 30 Dec 2002 08:46:22 -0600
Message-ID: <u8yy7mus3.fsf@standardandpoors.com>

On 29 Dec 2002, stuartc_at_mac.com wrote:
> Galen Boyer <galenboyer_at_hotpop.com> wrote in message

>> So, a way to guarantee that SQL code isn't in java code is to
>> have everything go through a proc.  Then, the database
>> actually looks much more java like anyways.  There is nothing
>> java/object like about dynamic SQL.  It is much more
>> java/object like to ask something to execute a method.

>
> The solution chosen depends a lot on your team & their skills,
> and the culture of your IT staff.
>
> For example, many DBA organizations in my experience will not
> write stored procs for developers (no time or motivation), yet
> the developers aren't very good at dealing with the database.
> So why bother (unless there's a technical reason like lots of
> data to process)? It's really a matter of having tech lead(s)
> that know detailed database issues and can coach the
> programmers on this.

I don't see a reason that even the simplest sql could be a proc and that the java developers even code these procs. I don't see any reason why the java developers need to be shielded from the database. The code needs to be, not the developers.

> In a small team, I've managed to get people to use
> PreparedStatement bind variables, SQL*PLUS autotrace, and write
> their JDBC in a repeatable, maintainable manner, so we can tune
> them as we study our TKPROF outputs.
>
> With a larger or dispersed team, this is harder to do. In
> those situations it makes sense to wrap procs with static
> methods in Java.
>
> Another solution I've tried with mixed results is to use
> TOPLink, where I could control the configuration (ensuring bind
> variables, etc), the developers got their nice-nice OO
> interface, and I can hunt down features that should be procs.

Does Toplink support procs for CMP? That would be a reason to get it. I didn't know CMP could handle procs. That would be way cool. Truly the best of both worlds there.

>
> I would work with the DBAs to ensure generated queries were
> sane, perhaps add needed SQL hints... it can work but TOPlink
> is quite pricy & complex and really needs a good justification
> beyond "we don't know SQL!".

Price isn't really an issue where I work. Functionality/price is.

-- 
Galen Boyer

Received on Mon Dec 30 2002 - 08:46:22 CST