Depends on the queries I would say.  If they are pretty stock standard
queries then I guess a stored proc process would be ok.  Me personally I
prefer all or nothing.  If you go down the stored proc route then I would be
wanting everything in there.

Another thing to consider is who is going to be managing the SQL side of
things.  You need to make sure that you can manage them easily if it is
going to be your responsibility.

Steve 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of felixt
Sent: Monday, 12 January 2009 12:19 PM
To: cfaussie
Subject: [cfaussie] Using stored procedure exclusively to control database
access


Hi all,

It has been suggested by someone at work that we should only allow
access to database via stored procedures.

This was proposed to fix the current situation where we have hundreds
of similar SQL statements scattered
around the system. For example if the business logic has changed in
one place that affects a table, one needs to do a keyword search on
all files to make sure all the related files are updated.

I am aware of the benefits of going the stored procs way, like:
1. Centralized place for logic
2. Faster execution
3. It's very unlikely that we will go with different database system
other than MSSQL so portability is not an issue for us.

But I feel a bit uneasy about this, I don't feel business logic should
be in the database also I think debugging stored procedure will be
more difficult (adding one more place to check).
But this is just my feel, I might be wrong.

Any thoughts, is this a normal/recommended practice? Also what are the
best practices that you guys use to combat this scattered SQL
statements?
I thought of using CFCs (gateways and/or DAOs) should be sufficient:
CFM -> CFC -> query
rather than:
CFM -> CFC -> stored proc

Cheers,

Felix



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"cfaussie" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/cfaussie?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to