Re: stored proc vs sql query string

surabhi(dot)ahuja(at)iiitb(dot)ac(dot)in ("surabhi.ahuja") writes:
> i have heard somewhere that writing a stored procedure, is much
> better than firing a sql query(such as select * from
> table_name) onto the database.
>
> is it true and if yes how?

It can be way more efficient.

Consider two alternative ways of handling some complex processing:

1. Pull all the data via SELECT * FROM TABLE_NAME, and process that
row by row, on the client.

2. Pull the data in as a SELECT inside a stored procedure, where
processing takes place inside the stored procedure.

In the first case, ALL the data has to be drawn into memory on the
database server, then marshalled, then passed over to the client,
possibly across a network connection. Processing then takes place on
the client, and updates may have to be passed back, one by one, across
the network connection, to the server.

In the second case, the same data is drawn into memory on the server.
It doesn't have to be transformed to be communicated to the client,
and there will be no substantial processing that takes place on the
client.

There's *substantial* savings in processing to be had by using stored
procedures.

> also i want to know that is the performnance in java slower as
> compared to cpp, given that the same things is being done.

There is no a priori reason to expect Java code accessing a database
to be either slower or faster than C++ code doing something
equivalent. Commonly, database I/O is the performance bottleneck,
which would point to language choice being irrelevant.

You have given no reason to distinguish between any cases...
--
let name="cbbrowne" and tld="ntlug.org" in String.concat "@" [name;tld];;
http://cbbrowne.com/info/sap.html
Rules of the Evil Overlord #81. "If I am fighting with the hero atop a
moving platform, have disarmed him, and am about to finish him off and
he glances behind me and drops flat, I too will drop flat instead of
quizzically turning around to find out what he saw."
<http://www.eviloverlord.com/>