2010-08-16 8 views
3

Lorsque itérer un Resultset de façon standardJava Resultset.get *** (...) plus rapide par string ou int?

while (rs.next()){ 
... 
} 

Pour récupérer les données de colonne (par exemple long) est-il plus rapide à utiliser

rs.getLong(String columnLabel) 

ou

rs.getLong(int columnIndex) 

On peut supposer que columnLabel est mieux à utiliser de plusieurs façons pour un code plus fort, mais y a-t-il une perte opérationnelle significative en faisant correspondre une colonne à la chaîne à chaque fois (nous parlons des tailles de table de ~ 40m lignes)?

+9

D'abord, faites-le fonctionner. Ensuite, faites-le maintenable. seulement ensuite, profiler et optimiser les goulots d'étranglement identifiés. Ne pas optimiser prématurément. – KeatsPeeks

+0

Bon conseil. J'étendais une classe abstraite à partir d'une bibliothèque qui suivait le modèle getLong (int), même si les noms de colonne étaient tous spécifiés en tant que champs. Cela me semblait un peu bizarre, alors je me demandais s'il y avait une bonne excuse pour ce morceau de code! Apparemment pas, il semblerait ... – sawu

+1

pourquoi est-ce que personne n'a vraiment répondu à la question, tout le monde semble avoir une opinion que l'optimisation est une perte de temps – jasonk

Répondre

0

Je vous suggère de réfléchir davantage à ce qui est plus clair que ce qui est plus rapide.

Voici un exemple: Supposons que vous avez une requête, select * from .... et quand vous itérer sur ResultSet, vous appelez String a = resultSet.getString(1), int i = resultSet.getInt(2) etc etc

Ensuite, vous changer votre définition de la table afin que vous avez d'autres colonnes ... tout d'un coup tous vos get vont casser parce que vous avez référé tout par int. Si vous avez référencé par nom de colonne, il n'y aura pas de pause.

Pour moi, cela semble beaucoup plus clair que le référencement par numéro de colonne. Vous économiserez également beaucoup de temps plus tard en essayant de déboguer votre ancien code pour comprendre pourquoi il se casse.

+0

Tout à fait d'accord. C'est le point que j'ai lissé avec élégance avec la ligne «mieux vaut utiliser de plusieurs façons pour un code plus fort». – sawu

0

Dépend entièrement de la structure interne. S'ils exploitent une sorte de cache, ce ne sera pas une grosse affaire. S'ils utilisent une hashmap, il est peu probable qu'elle soit substantielle. Un système conçu pour supporter cela n'aura pas trop de mal à faire face. Cependant, vous devriez vraiment penser à ce qui a plus de sens dans le contexte de votre code, et y revenir si un profil présente des problèmes de performances.

3

Je parierais que par rapport au coût de préparation du jeu de résultats, la différence est négligeable. Favoriser le code robuste.

1

Vous pouvez avoir le meilleur des deux! La rapidité d'utilisation des index avec la maintenabilité et la sécurité de l'utilisation des noms de colonnes. Tout d'abord, sauf si vous utilisez un jeu de résultats, utilisez simplement les noms de colonnes.

1.Définissez un ensemble de variables entières, une pour chaque colonne à laquelle vous aurez accès. Les noms des variables peuvent inclure le nom de la colonne: par ex. iLast_Name.

2.Avant que la boucle de jeu de résultats parcoure les métadonnées de la colonne, définissez la valeur de chaque variable entière sur l'index de colonne du nom de colonne correspondant. Si l'index de la colonne 'Last_Name' est 3, définissez la valeur de 'iLast_Name' sur 3.

3.Dans la boucle de jeu de résultats, utilisez les noms de variables entières dans les méthodes GET/SET. Le nom de la variable est un indice visuel pour le développeur/responsable quant au nom de la colonne en cours d'accès mais la valeur est l'index de la colonne et donnera les meilleures performances. REMARQUE: le mappage initial (c'est-à-dire le mappage du nom de la colonne à l'index) est effectué une seule fois avant la boucle plutôt que pour chaque enregistrement et chaque colonne de la boucle.

+0

Etes-vous sûr que ce serait plus rapide? serait bien de voir un exemple de code. – Zarathustra