a) J'ai remarqué qu'il y a parfois un peu de confusion lorsqu'on utilise le tag cfquery :
<cfquery name="myQuery">SELECT 1 FROM DUAL</cfquery>
Notes : En CF9 l'attribut datasource est devenu optionnel, vu qu'on peut définir une source de données globale pour toute l'application (dans le fichier « application.cfc »).

Dans l'exemple précédent, le nom « myQuery » est le nom d'une variable. En fait, ce code pourrait être écrit : <cfset myQuery = "" /> <cfquery name="myQuery">SELECT 1 FROM DUAL</cfquery>
Dans ce sens, rien ne vous empêche d'écrire :
<cfquery name="REQUEST.myTemplate.myQuery">SELECT 1 FROM DUAL</cfquery>
Cela revient à écrire :
<cfset REQUEST.myTemplate = StructNew() /> <cfquery name="REQUEST.myTemplate.myQuery">SELECT 1 FROM DUAL</cfquery>
Notes : Cette pratique (spécialiser les variables par page ou fonctionnalité) peut être intéressante si vous voulez bien encapsuler vos traitement (ainsi éviter une utilisation accidentel d'une autre variable) et au même temps si vous allez avoir un moyen facile de passer des paramètres entre composants qui ne partagent pas le scope VARIABLES.

b) pour les fonctions, je recommande la syntaxe explicite suivante (question de sécuriser le code) :
<cffunction name="doQuery"> <cfset var myQuery = "" /> <cfquery name="myQuery">SELECT 1 FROM DUAL</cfquery> </cffunction>
Mais je trouve cette syntaxe un peu contraignante, surtout lorsqu'il y a plusieurs variables à initialiser, et en plus il faut mettre toutes les déclarations des variables au top de la fonction juste après les tags CFARGUMENT (uniquement pour les versions antérieures à CF9).

CF9 ajoute un nouveau scope LOCAL qui est privé au code de la fonction, c.-à-d., les variables déclarées dans ce scope ne sont pas visibles à l'extérieur de la fonction. <cffunction name="doQuery"> <cfquery name="LOCAL.myQuery">SELECT 1 FROM DUAL</cfquery> </cffunction>
Pour les versions antérieures à CF9, je recommande la syntaxe suivante :
<cffunction name="doQuery"> <cfset var LOCAL = StructNew() /> <cfquery name="LOCAL.myQuery">SELECT 1 FROM DUAL</cfquery> </cffunction>

On signale que l'utilisation de cfqueryparam permet d'avoir des gains de performance.
La première chose à savoir est que le gain de performance n'est pas une particularité de ColdFusion mais une option du SGBD, s'il supporte les "bind variables".
Voici un résumé des fonctionnalités du tag cfqueryparam :

• [du coté ColdFusion] forcer le teste sur le type des valeurs (ce teste peut être aussi effectué avec le tag CFPARAM) ;
  
  
• [du coté ColdFusion] sécuriser les paramètres (attaques par injection SQL), principalement pour les variables qui viennent de l'extérieur du serveur (Scope FORM, URL, …) ;
  
  
• [du coté SGBD] avoir des gains de performances dans le cas des requêtes dynamiques et répétitives (si le SGBD supporte les BIND VARIABLES).
  

Pour les gains de performances, si on considère une requête qui ramène des informations pour une ressource donnée :
<cfquery name="myQuery"> SELECT (…) FROM (…) WHERE id = <cfqueryparam cfsqltype="CF_SQL_INTEGER" value="#RES_ID#" /> </cfquery>
Le tag cfqueryparam va permettre au SGBD (Oracle par exemple) de créer une BIND VARIABLE pour la variable RES_ID et dans ce cas il ne sera pas obligé d'établir un nouveau plan d'exécution lors de la prochaine requête (donc éviter de parser la requête, établir le meilleur plan d'exécution, …).

À défaut de ne pas utiliser cfqueryparam, Oracle va considérer que chaque requête, qui vient avec une valeur différente pour RES_ID, est unique et donc il va établir un nouveau plan d'exécution.

Par contre, il n'est pas nécessaire d'utiliser le tag cfqueryparam lorsque la valeur d'une variable est statique (et on sait d'avance que la requête ne va pas utiliser une autre valeur pour cette variable) :
<cfquery name="myQuery"> SELECT 1 FROM tblSTATUS WHERE code = <cfqueryparam value="B" cfsqltype="CF_SQL_CHAR" /> </cfquery>
Dans ce cas, mieux privilégier :
<cfquery name="myQuery"> SELECT 1 FROM status WHERE code = 'B' </cfquery>
Il n'y a aucun besoin dans ce cas pour qu'Oracle crée une BIND VARIABLE.