struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yang, Pedro" <Pedro.Y...@schwab.com>
Subject RE: [OT] What do you do with your SQL?
Date Fri, 26 Jul 2002 20:57:11 GMT
Where you actually place your SQL logic (statements) sometimes has a lot to
do: 
(1) what DBMS your system is using (MS SQL Server, Oracle, to name a few); 
(2) what DB development resource and knowledge your team has. 

If a right DBMS is used, with the sufficient DB knowledge, the stored
procedures can be a good solution. 
The common pitfall with this approach is to hardcode the SP name and
parameters in the Java codes.  To avoid this problem, you can store the
values in a xml file.

-----Original Message-----
From: Struts Newsgroup [mailto:struts@basebeans.com]
Sent: Friday, July 26, 2002 1:40 PM
To: struts-user@jakarta.apache.org
Subject: Re: [OT] What do you do with your SQL?


Subject: Re: [OT] What do you do with your SQL?
From: Vic C <vic@basebeans.com>
 ===
Think about it the other way, make your application information driven.

For example:
Select * from rules where client = a

and client_id or org_id to every table.

Think about it for a bit with a SQL expert (SQL Expert == someone with 7 
years or more of SQL deployment).
Vic




Nelson, Tracy (ETW) wrote:
> I once prototyped a system where I  kept all the SQL statements in the
> database itself.  The original intent was to take the statements and
> actually compile them into stored procedures, but the project was dropped
> before that part was finished.
> 
> Cheers!
> -- Tracy Nelson
> 
> -----Original Message-----
> From: Assenza, Chris [mailto:cassenza@Accessdc.com]
> Sent: Friday, July 26, 2002 13:17
> To: 'Struts Users Mailing List'
> Subject: [OT] What do you do with your SQL?
> 
> 
> Hi all, 
> 
> Been a while since I last wrote, but I've been lurking to observe all the
> crazy antics. :)  Anyway, I've got a question of an [ot] nature that I
> believe you folks will have an answer for. 
> 
> Our application is highly data-driven and as such a lot of our "business
> logic" is written to build SQL statements and handle query results.
Pretty
> typical stuff.  Using Struts we pass data objects to a stateless session
EJB
> where all the SQL is directly embedded into the java source one way or
> another.  
> 
> We're currently converting this custom app into a product. As such, we
need
> to be able to have easily modifiable SQL statements without requiring
> recompilation of code.  For example, if client A decides to buy our app
and
> they have xyz infrastructure or business rules, we need to be able to
easily
> modify sql, hints and the like while also supporting the client-specific
> sql, hints, etc. of client B.  
> 
> A lot of our SQL is built on the fly so using properties files may be a
> little cumbersome, though certainly not beyond our means.  I have other
> ideas floating around, but I'd rather just hear yours - any suggestions? 
> 
> Thanks,
> 
> Chris
> 
> 
> --
> To unsubscribe, e-mail:
> <mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:struts-user-help@jakarta.apache.org>
> 
> 
> 
> --
> To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>
> 


--
To unsubscribe, e-mail:
<mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-user-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:struts-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-user-help@jakarta.apache.org>


Mime
View raw message