I favour stored procs, figure the db knows how to do its job better
then coldfusion and blah blah re-use amongst other technologies blah
blah..

That being said, if i do go down the CFQUERY route, i'm a stickler for
code pretty. I prefer the at a glance scan, meaning if i have to
backtrack and read left to right in order to find a param or can't
summaries a query based on a top down approach, i get somewhat
annoyed..


eg:

SELECT  param1,
        param2,
        param3,
        param4,
        param5

FROM    tableX
        LEFT JOIN tableY
        ON (tableX.param1 = tableY.param3)

        LEFT JOIN tableY
        ON (tableX.param1 = tableY.param3)

WHERE   param1  IN      (       SELECT  param1
                                FROM    tableN
                                WHERE   param9 = <cfsqlparam..?/> )

ORDER BY monkey, butts, rule
GROUP BY SQL, code, syntax, iswrong, iknow.

(ignore the SQL and focus on how its indented)



On 8/17/05, Chad Renando <[EMAIL PROTECTED]> wrote:
> Yeah, to give you an idea, I have one form processing page and one
> form generating page for my entire app.  Because I often don't know
> what will be thrown at the query, I need to define it before hand and
> then generically run the query based on the variables thrown at it.
> It is a bit of an experiment in code once, code well.
> 
> Which brings up another interesting q8uestion as far as when to
> separate out into separate pages.  I am going down the path of having
> literally everything on the one .cfm page and just throwing variables
> at it and processing through Ajax / Javascript.
> 
> Chad
> who feels like he was defined beforehand
> 
> On 8/17/05, Gary Menzel <[EMAIL PROTECTED]> wrote:
> > The issue you may have with this is that by doing it that way you cannot use
> > <cfqueryparam> and hence you may have problems with SQL Injection statements
> > (where someone can hijack pages/queries with what they enter into form
> > fields - unless you have strong filtering and validation on the form
> > fields).
> >
> > Regards,
> > Gary
> >
> >
> > On 8/17/05, Chad Renando <[EMAIL PROTECTED]> wrote:
> > >
> > > Personally, I keep CF out of my SQL as much as possible, which means
> > > putting SQL in my CF variables.  Often times, my queries look
> > > something like:
> > >
> > > SELECT #MySelectStatement#
> > > FROM #MyFromStatement##MyJoinStatement#
> > > #MyWhereStatement#
> > > #MyGroupStatement#
> > > #MyOrderStatement#
> > >
> > > But then I'm abstracting to the nth degree.
> > >
> > > Chad
> > > who is cold and turning his thermostat to the nth degree
> > >
> > > On 8/17/05, [EMAIL PROTECTED] <[EMAIL PROTECTED] >
> > wrote:
> > > > Who cares? The sql server doesnt ... but really it comes back to the
> > KISS
> > > > prinicple. The easier someone can read your code the better it is. The
> > > > greatest cost of any development is the maintenance. You ever look at
> > your
> > > > own code from three years ago and go 'What the ...'. Im very much in
> > > > favour of the CF identation method.
> > > >
> > > > my 2c
> > > >
> > > > > Hi All
> > > > >
> > > > > Just wondering what everyones opinion is about formatting SQL code
> > > > > withing CFQuery ? Do you think its important to preserve the
> > indentation
> > > > > of the SQL or is it more important to see the flow of the CF code
> > inside
> > > > > the tag ?
> > > > >
> > > > > Im way more in favour of preserving cold fusion indentation. I just
> > > > > think its more important to follow the logic of the code, especially
> > > > > when the query gets complex and there are more <CFIF calls in there.
> > > > >
> > > > > Pat
> > > > >
> > > > >
> > > > > eg. SQL indentation is Preseved
> > > > >
> > > > > <cfquery .....>
> > > > > SELECT *
> > > > > FROM table t
> > > > > WHERE 0=0 <cfif isDefined("form.keyword") >
> > > > > AND title like '%#title#%'</cfif><cfif listLen( form.categoryIds) >
> > > > > AND category_id IN (#form.categoryIDs#)</cfif>
> > > > > </cfquery>
> > > > >
> > > > > OR 2 cold fusion indentation is preserved
> > > > >
> > > > > <cfquery .....>
> > > > > SELECT *
> > > > > FROM table t
> > > > > WHERE 0=0
> > > > > <cfif isDefined("form.keyword") >
> > > > >       AND title like '%#title#%'
> > > > > </cfif>
> > > > >
> > > > > <cfif listLen(form.categoryIds) >
> > > > >       AND category_id IN (#form.categoryIDs#)
> > > > > </cfif>
> > > > > </cfquery>
> > > > >
> > > > > ---
> > > > > You are currently subscribed to cfaussie as:
> > [EMAIL PROTECTED]
> > > > > To unsubscribe send a blank email to
> > > > > [EMAIL PROTECTED]
> > > > > Aussie Macromedia Developers: http://lists.daemon.com.au/
> > > > >
> > > >
> > > >
> > > >
> > > > ---
> > > > You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
> > > > To unsubscribe send a blank email to
> > [EMAIL PROTECTED]
> > > > Aussie Macromedia Developers: http://lists.daemon.com.au/
> > > >
> > >
> > > ---
> > > You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
> > > To unsubscribe send a blank email to
> > [EMAIL PROTECTED]
> > > Aussie Macromedia Developers: http://lists.daemon.com.au/
> > >
> >
> >  --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To
> > unsubscribe send a blank email to
> > [EMAIL PROTECTED] Aussie Macromedia
> > Developers: http://lists.daemon.com.au/
> 
> ---
> You are currently subscribed to cfaussie as: [EMAIL PROTECTED]
> To unsubscribe send a blank email to [EMAIL PROTECTED]
> Aussie Macromedia Developers: http://lists.daemon.com.au/
> 


-- 
Regards,
Scott Barnes
http://www.mossyblog.com

---
You are currently subscribed to cfaussie as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/

Reply via email to