Why not embed the SQL in a bean and return a dynamically sizable
array? Then the JSP page is independant of the database type - totally
independant - and you can have multiple beans (if needed) to hit
different DB's and use SP's if you like :)
I use a private method that takes in the SQL statement (or just the
where clause) and returns a Vector. This is the converted into whatever
the calling function needs - a single record, and array etc. If you
NEEDED to abstract it
(but the java datatypes that were returned, eg a "struct" (well, class
with public variables) stayed constant), then have a generic DB type
that returns what you want and override the SQL-calling method, which
returns the Vector.
As to the original question :) - which ever works. For a select, I'd go
with
a SQL statement, for an update or insert, if it covers multiple tables,
I'd go with an SP. If its just a one-off, SQL. It depends very much on
which DB you are hitting.
N
Christopher Cobb wrote:
>
> Brian Burridge wrote:
>
> > I just wanted to get some of your opinions on this. We are having an
> > internal discussion about whether or not to use stored procedures for
> > our SQL, or to put the SQL in the bean or JSP page.
>
> If you live and breath performance at any cost, use stored procedures.
>
> If you want better portability between database, stay in Java.
>
> cc
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
