L'objet String est lourd � manipuler car lors d'ajout, un nouveau objet String est cr�� � chaque fois tandis que l'objet StringBuffer n'est cr�� qu'une fois et qu'il peut "vivre" (ajout, suppression...)
Dans le cas pr�sent c'est presque �quivalent :
"SELECT * FROM " + username + ".NOM_TABLE"; cr�e 4 objets String : 1 : "SELECT * FROM " 2 : ".NOM_TABLE" 3 : "SELECT * FROM " + username = debut 4 : debut + ".NOM_TABLE"
tandis qu'avec un StringBuffer il y 3 objets String et un objet StringBuffer :
1 : StringBuffer sbTmp=new StringBuffer(); 2 : "SELECT * FROM " 3 : ".NOM_TABLE" 4 : sb.toString();
mais on voit que s'il y a plein de concat�nations de texte (et c'est souvent le cas en SQL avec les param�tres) le StringBuffer est plus rapide car il y a moins de cr�ation d'objet.
Eric
Aurelien Mazurie a �crit:
Bonjour � tous,
Ce bout de code me rappelle que j'ai toujours �t� intrig� par les StringBuffer:
Salut,
Ceci devrait r�soudre ton probl�me :
StringBuffer sbTmp=new StringBuffer(); sb.append("SELECT * FROM "); sb.append(username); sb.append(".NOM_TABLE");
Ensuite tu cr�es le statement avec sb.toString(); Y.E.
Pour ce genre de cas (ma question est ind�pendante du probl�me de requ�te SQL dont est tir� le code), quel est en fait l'int�r�t de passer par un StringBuffer/append plut�t qu'en concat�nant directement du String ?
ex: String query = "SELECT * FROM " + username + ".NOM_TABLE";
Pour des concat�nations si courtes, j'imagine (j'esp�re !) qu'il n'y a aucune diff�rence, mais o� est l'avantage d'utiliser StringBuffer ? Pour des cha�nes plus longues ? Pourtant on utilise rarement des grosses cha�nes de caract�re ?
Aur�lien Mazurie
