Hi all,
Thanks for the useful comments guys!!
It has brought some very good points that worth discussing with the
team here.
Cheers
Felix
On Jan 12, 1:02 pm, Barry Beattie barry.beat...@gmail.com wrote:
I think the key is
This was proposed to fix the current situation where we have
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
I know ppl sometimes use databases for just basic data storage but
business logic in a database is a very valid process, especially if
inserts, updates and deletes involve triggers of related data.
having said that, it's something I don't need to do all that often,
and usually reserve for
the biggest hassle with SP's is that you are stuck with one set of SP
for a database
ie you can't tweak SP's like you can with normal queries
if you use bound sql, you can have two different builds with different
sql accessing the same db, with sp's
you can only have one a big hassle
Hey Felix,
* Faster execution is definitely a benefit of stored procs for
intensive or repetitive tasks
* Centralised place for logic is definitely a good thing, but I would
suggest that it's better to have in ColdFusion not stored procs. In
some cases, not all business logic can be represented
A little late on this conversation but I will address the questions you have
down below.
There are a number of ways you could approach this, but the idea of having a
central logic storage is the best solution. For the reasons that it was
suggested, and this is where ORM's have tried to bridge
I think the key is
This was proposed to fix the current situation where we have hundreds
of similar SQL statements scattered
around the system
it's possibly worth trying to understand why this happened, as you've
identified this as a maintenance nightmare.
do you *need* to have all these
