Quel est le moyen le plus efficace pour accéder à la valeur d'un champ dans un jeu d'enregistrements ADO?

J'ai une application VB6 en face de moi, qui accède à des Bases de données Sql via ADO.

Lors de la récupération des jeux d'enregistrements, l'application utilise le Bang (!) les opérateurs d'accéder aux champs dans les jeux d'enregistrements par exemple RS!N ° de commande.

Pendant que je suis au courant de cette pratique, je n'ai jamais réellement utilisé(sauf quand j'ai été paresseux), et je n'ai pas utilisé RS("OrderId") comme je l'ai toujours (ou souvent) utilisé pleinement qualifié de la méthode (par exemple RS.champs("OrderId").de la valeur. ou même élargi elle a en outre l'aide de l' .Propriétés De L'Élément.)

Reviennent tous les deux exactement la même valeur, l'un est plus court à taper que les autres.

La raison pour laquelle j'ai collé de cette méthode est que parfois, dans le passé lointain, je crois que j'ai dit qu'il était plus performant pour obtenir le champ, comme le code a pour traduire chaque occurrence de la ! opérateur de son pleinement qualifié sœur. Cependant, l' ! l'opérateur réduit en tapant et en tant que tel dev temps.

J'ai aussi semble me rappeler que le ! pour ADO allait être obsolète à un certain moment dans l'avenir. Mais il semble toujours être autour dans le code, je me demandais quelle méthode est considérée comme la meilleure pratique et celui qui fonctionne mieux sur les autres.

Tous VB6 est plus ou moins obsolète, non? Le coup de l'opérateur n'est pas pris en charge .NET
Les plus performantes sont les méthodes ordinales; rs(index) ou de son (caché) nommé call rs.collecter(index) comme ils ont tous les deux éviter la liaison tardive généraux de ! et la clé de recherche c'est requise lorsque vous utilisez un nom de champ
Si vous êtes à la récupération de la totalité du jeu d'enregistrements et ne pas écrire en arrière, j'avais pense que c'rapide à utiliser GetRows().

OriginalL'auteur BrianBurkill | 2014-02-03

ado vb6

6

J'ai testé minutieusement les performances de VB6 et ADO pour les utiliser dans mon application. L'absolu de la façon la plus rapide pour obtenir des données à partir d'un jeu d'enregistrements est d'utiliser le CHAMP objet. Vous remarquerez une grande différence dans la performance lors du retour de beaucoup de lignes. Ce qui suit est un bloc de code à partir de mon application (réduit à mettre en évidence la bonne utilisation des objets de champ).
```
Dim fMinLongitude As ADODB.Field
Dim fMinLatitude As ADODB.Field
Dim fMaxLongitude As ADODB.Field
Dim fMaxLatitude As ADODB.Field
Dim fStreetCount As ADODB.Field

If RS.RecordCount = 0 Then
    Exit Sub
End If

Set fMinLongitude = RS.Fields.Item("MinLongitude")
Set fMinLatitude = RS.Fields.Item("MinLatitude")
Set fMaxLongitude = RS.Fields.Item("MaxLongitude")
Set fMaxLatitude = RS.Fields.Item("MaxLatitude")
Set fStreetCount = RS.Fields.Item("StreetCount")

While Not RS.EOF
    LineGridCount = LineGridCount + 1
    With LineGrid(LineGridCount)
        .MinLongitude = fMinLongitude.Value
        .MaxLongitude = fMaxLongitude.Value
        .MinLatitude = fMinLatitude.Value
        .MaxLatitude = fMaxLatitude.Value
    End With
    RS.MoveNext

Wend

RS.Close
Set RS = Nothing
```
Note que j'ai mis des objets de champ pour 5 colonnes retournées par une procédure stockée SQL Server. J'ai ensuite utiliser à l'intérieur d'une boucle. Quand vous faites RS.MoveNext, il affecte le domaine des objets.

Avec le code indiqué ci-dessus, je peux charger de 26 000 lignes dans mon type défini par l'utilisateur en moins de 1 seconde. En fait, l'exécution du code, il a pris de 0,05 secondes. Dans l'application compilée, c'est encore plus rapide.

Si vous n'utilisez pas d'objets de champ, alors vous devez au moins utiliser un bloc. Comme mentionné dans un autre post, en utilisant la position ordinale est plus rapide que d'autres (à l'exception de la méthode de champ). Si vous prévoyez sur l'utilisation de la position ordinale, alors vous devriez utiliser un bloc. Par exemple:
```
With RS.Fields
  ID = .Item(0).Value
  Name = .Item(1).Value
  EyeColor = .Item(2).Value
End With
```
À l'aide d'un bloc est agréable, car il réduit la quantité de frappe et en même temps, il accélère l'exécution du code. Cette augmentation des performances se produit parce que VB pouvez définir un pointeur vers le champ de l'objet une fois et puis de réutiliser le pointeur pour chaque appel vers les champs de l'objet.

En passant... je n'aime pas le "moins tapant" argument. Je trouve souvent que la meilleure exécution de code est également un code plus complexe. Avec VB6 l'intellisense, la saisie de texte supplémentaire n'est pas tout ce que beaucoup soit.

RS("FieldName") est de 15 caractères.

J'ai pris l'habitude de taper: r s (dot) f (dot) i (parenthèse ouvrante) (citation) FieldName (citation) (fin de Parenthèse) (dot) v. C'est 6 extra touches pour utiliser pleinement qualifié de la méthode.

L'aide de la méthode des blocs, il serait (dot) i (parenthèse ouvrante) (citation) FieldName (citation) (fin de parenthèse) (dot) v, qui est de 17 touches.

C'est l'une de ces situations où une bonne habitude prend peu d'effort et rapporte gros en ayant une meilleure exécution de code.

Je viens de faire quelques tests de performance. Le test suivant utilise un curseur côté client qui signifie que toutes les données renvoyées par la requête est copié sur l'ordinateur client et stocké dans l'objet recordset.

Le code que j'ai utilisé pour le test de performance est ceci:
```
Private Sub Command1_Click()
Dim DB As ADODB.Connection
Dim RS As ADODB.Recordset
Dim Results() As String
Set DB = New ADODB.Connection
DB.ConnectionString = "my connection string here"
DB.CursorLocation = adUseClient
DB.Open
Set RS = New ADODB.Recordset
Call RS.Open("Select * From MapStreetsPoints", DB, adOpenForwardOnly, adLockReadOnly)
Dim Start As Single
Dim FeatureId As Long
Dim PointNumber As Long
Dim Longitude As Single
Dim Latitude As Single
Dim fFeatureId As ADODB.Field
Dim fPointNumber As ADODB.Field
Dim fLongitude As ADODB.Field
Dim fLatitude As ADODB.Field
ReDim Results(5)
RS.MoveFirst
Start = Timer
Do While Not RS.EOF
FeatureId = RS!FeatureId
PointNumber = RS!PointNumber
Longitude = RS!Longitude
Latitude = RS!Latitude
RS.MoveNext
Loop
Results(0) = "Bang Method: " & Format(Timer - Start, "0.000")
RS.MoveFirst
Start = Timer
Do While Not RS.EOF
FeatureId = RS.Fields.Item("FeatureId").Value
PointNumber = RS.Fields.Item("PointNumber").Value
Longitude = RS.Fields.Item("Longitude").Value
Latitude = RS.Fields.Item("Latitude").Value
RS.MoveNext
Loop
Results(1) = "Fully Qualified Name Method: " & Format(Timer - Start, "0.000")
RS.MoveFirst
Start = Timer
Do While Not RS.EOF
FeatureId = RS.Fields.Item(0).Value
PointNumber = RS.Fields.Item(1).Value
Longitude = RS.Fields.Item(2).Value
Latitude = RS.Fields.Item(3).Value
RS.MoveNext
Loop
Results(2) = "Fully Qualified Ordinal Method: " & Format(Timer - Start, "0.000")
RS.MoveFirst
Start = Timer
With RS.Fields
Do While Not RS.EOF
FeatureId = .Item("FeatureId").Value
PointNumber = .Item("PointNumber").Value
Longitude = .Item("Longitude").Value
Latitude = .Item("Latitude").Value
RS.MoveNext
Loop
End With
Results(3) = "With Block Method: " & Format(Timer - Start, "0.000")
RS.MoveFirst
Start = Timer
With RS.Fields
Do While Not RS.EOF
FeatureId = .Item(0).Value
PointNumber = .Item(1).Value
Longitude = .Item(2).Value
Latitude = .Item(3).Value
RS.MoveNext
Loop
End With
Results(4) = "With Block Ordinal Method: " & Format(Timer - Start, "0.000")
RS.MoveFirst
Start = Timer
Set fFeatureId = RS.Fields.Item("FeatureId")
Set fPointNumber = RS.Fields.Item("PointNumber")
Set fLatitude = RS.Fields.Item("Latitude")
Set fLongitude = RS.Fields.Item("Longitude")
Do While Not RS.EOF
FeatureId = fFeatureId.Value
PointNumber = fPointNumber.Value
Longitude = fLongitude.Value
Latitude = fLatitude.Value
RS.MoveNext
Loop
Results(5) = "Field Method: " & Format(Timer - Start, "0.000")
Text1.Text = "Rows = " & RS.RecordCount & vbCrLf & Join(Results, vbCrLf)
End Sub
```
Les résultats sont les suivants:
```
Rows = 2,775,548
Bang Method: 9.441
Fully Qualified Name Method: 9.367
Fully Qualified Ordinal Method: 5.191
With Block Method: 8.527
With Block Ordinal Method: 5.117
Field Method: 4.316
```
Clairement la méthode de champ est le gagnant. Il prend moins de 1/2 le temps de le bang méthode. Notez également que l'ordinal méthodes ont également des performances décentes par rapport à la méthode de champ.

Cependant rs!fieldname (même sans ajouter .La valeur n'est que d'environ 40% pire que rs.Fields.Item(index).Value, et il est 40% plus de une assez petite quantité de temps CPU. Je ne doute pas de la valeur optimale des habitudes, mais les gains peuvent être assez minuscule, de l'ordre de 1,5 secondes ou moins pour 1 million de lignes.
le point que j'essayais de faire passer est que, AVEC les blocs auront un grand impact sur les performances. Si une personne n'est pas prêt à passer par l'effort de l'aide ADODB.Les champs, que ce qu'ils devraient au moins utiliser AVEC des blocs et des ordinaux. En outre, de petites quantités de temps de calcul peut ajouter jusqu'à de grands retards pour l'utilisateur et la faiblesse de l'application.
Je suis d'accord avec tous vos points, c'est pourquoi j'ai voté votre réponse. J'ai tout à fait en désaccord que ce type d'optimisation fait une énorme différence dans la plupart des programmes... si la mise en cache fortement utilisé les références de l'objet (de manière explicite ou via Avec) peut obtenir le plus de "bang" pour l'effort. Notez que cela peut également être utilisé avec le bang de la syntaxe, tout comme .Value peut.
J'aime bien le "Champs" de la méthode, mais j'ai éloigner de l'Ordinal méthodes en raison d'une expérience passée, lors de l'une de mes équipe a utilisé RS(0),(1),(2) etc. Il a bien fonctionné et a été promu en direct. Une autre personne dans une autre équipe a décidé d'utiliser exactement la même procédure (comme il se doit), mais au lieu d'ajouter des champs à la sortie, il a inséré, et déployé en direct. Tout d'un coup, mon gars application est tombée. J'ai tout de suite imposé une règle de ne jamais l'ajout de champs à la sortie. Mais quelqu'un a ignoré et c'est encore arrivé, donc j'ai banni l'utilisation de l'ordinal de domaines allant de l'explicite de la méthode de nommage.
Encore une fois, les Champs de la méthode la plus performante. Si vous regardez mon exemple, vous définissez chaque champ objet basé sur le nom du champ (pas l'ordinal). Vous obtenez le meilleur des deux mondes. Vous disposez d'un code qui ne dépend pas de la position ordinale et même plus performant que les méthodes ordinales. En gros, c'est plus rapide et plus fiable.

OriginalL'auteur G Mastros
1

Projet de loi Vaughn a eu une bonne discussion de ce point dans son article "ADO Performances les Meilleures Pratiques". La conclusion, comme indiqué par Alex K dans le commentaire, est d'utiliser un ordinal comme rs(0) ou rs(7).

Projet de loi a également discuté d'une technique d'utilisation d'un enum pour fournir des noms lisibles pour les positions d'index. Par exemple, une requête du genre:
```
SELECT CatName, CatType, CatSize from Cats Where...
```
Vous pourriez avoir ce enum dans VB:
```
Enum enuCatsQuery
CatName
CatType
CatSize
End Enum
```
Et ce code pour accéder au champ:
```
StrMyName = Rs(enuCatsQuery.CatName)
```
J'aime bien le "Champs" de la méthode, mais j'ai éloigner de l'Ordinal méthodes en raison d'une expérience passée, lors de l'une de mes équipe a utilisé RS(0),(1),(2) etc. Il a bien fonctionné et a été promu en direct. Une autre personne dans une autre équipe a décidé d'utiliser exactement la même procédure (comme il se doit), mais au lieu d'ajouter des champs à la sortie, il a inséré, et déployé en direct. Tout d'un coup, mon gars application est tombée. J'ai tout de suite imposé une règle de ne jamais l'ajout de champs à la sortie. Mais quelqu'un a ignoré et c'est encore arrivé, donc j'ai banni l'utilisation de l'ordinal de domaines allant de l'explicite de la méthode de nommage.
Oui, c'est certainement l'un des compromis, comme mentionné dans l'article. Un autre exemple de la façon dont la performance et la facilité de maintenance sont souvent en contradiction les uns avec les autres!

OriginalL'auteur Holistic Developer

Vous devez vous connecter pour publier un commentaire.