#27 | アクションクエリーのレコードロックを考える | |||||||||||||||||||||||||
このアクションクエリーのレコードロックも、「#26 アクションクエリーのトランザクションを考える」に類似したテストです。アクションクエリーのクエリープロパティとして用意された、「レコードロック」の設定によるパフォーマンスを比較します。このプロパティには、アクションクエリー実行中に、全レコードに対してロックをかける"すべてのレコード"と、編集済みレコードだけを対象とする"編集済みレコード"のいずれかを指定します。
テストに使うコードは次のようなものです。DoCmd.OpenQuery の行の右に書かれた番号が、テストパターンの各番号を表しています。 Sub TestQryRecLock() DoCmd.SetWarnings False ts_Watch "テスト開始", True '編集済みレコードのみロックする場合のテスト DoCmd.OpenQuery "更新クエリ_デフォルト"・・・・・・1 ts_Watch "編集済みのみロック 更新" DoCmd.OpenQuery "追加クエリ_デフォルト"・・・・・・2 ts_Watch "編集済みのみロック 追加" DoCmd.OpenQuery "削除クエリ_デフォルト"・・・・・・3 ts_Watch "編集済みのみロック 削除" 'すべてのレコードをロックする場合のテスト DoCmd.OpenQuery "更新クエリ_全レコードロック"・・・・・・4 ts_Watch "全レコードロック 更新" DoCmd.OpenQuery "追加クエリ_全レコードロック"・・・・・・5 ts_Watch "全レコードロック 追加" DoCmd.OpenQuery "削除クエリ_全レコードロック"・・・・・・6 ts_Watch "全レコードロック 削除" DoCmd.SetWarnings True End Sub テスト結果は次の通りです。 更新クエリーと削除クエリーについては、明らかに、編集済みレコードのみにロックをかけた方がパフォーマンスが高いことが分かります。"レコードをロックする"という制御処理には、その対象となるレコード数に応じて、それ相応のオーバーヘッドがかかるということの表れではないでしょうか。あるいは、他のユーザーがそれらのレコードに対して何らかの編集操作を行っていないか、その監視処理の時間もかかっているかもしれません。 一方、追加クエリーについては、更新クエリーや削除クエリーに比べてその差異は小さいものの、すべてのレコードにロックをかけた方がパフォーマンスが高くなっています。これは、想像の域を出ませんが、更新クエリーや削除クエリーが既存レコードに対してロックをかけるのに対して、追加クエリーは新規レコードに対してのみロックをかけていますので、それらのレコードについては共有的にアクセスされる可能性が低いことから、このような結果が出ているのではないかと考えられます。 このレコードロックの設定は、主にマルチユーザーデータベースでの排他制御のための設定です。シングルユースでは特にその設定を気にする必要はないと思われます。もし仮に複数のユーザーがデータベースを共有する場合でも、クエリーの「レコードロック」プロパティは、全般的にパフォーマンスが高い"編集済みレコード"がデフォルト設定になっていますので、やはりその設定を気にする必要はないといえるでしょう。ただし、追加クエリーについては、今回の両者の違いが微小であることを考えると、レコード数など、ケースバイケースで比較した方がよいでしょう。 しかしながら、マルチユーザーデータベースの場合には、処理時間だけでなく、データの整合性の面も十分考慮しなければなりません。そのために、全レコードにロックをかけてから編集処理を行った方が安全な場合も多々あります。そのような場合にはもちろん、スピードには関係なく、"すべてのレコード"を指定しなければなりません。 |
||||||||||||||||||||||||||
|
Copyright © T'sWare All rights reserved |