Microsoft SQL Server を使用しています。仮想キーについて

群馬のマジシャン

• 2021年03月18日 08:07

【インデックスタイプ】で、「V=仮想キー」をお使いでしょうか？

実キーとどのように使い分けされていらっしゃいますか？

 

• 

  tanda

  • 2021年03月19日 05:08

  使い分けというより、必要になったときだけ使えばいいと思います。

  ヘルプを見ると使い方の例が書いてあるようですね。
• 

  nkmt

  • 2021年03月19日 21:50

  他社構築のDBを読まないといけないけど、インデックスが無かったので、Magicのデータリポジトリに仮想キーを設定した事があります。

  自分で作った「お客様担当者マスタ」という物に、更新日の降順仮想キーを設定した事もあります。
  プログラム側でソートするのもありなのでしょうね。
  
  いろんな場面で並べる事が想定されたり、画面や帳票に表示印字する件数が少ない事がわかっていたりする場合など、使ってもいいのかもしれませんが、私の予想なので誤っているかもしれません。
• 

  ISHIJIMA

  • 2021年03月19日 22:34

  基本的には使用していません。

  ヘルプを見るとＤＢにインデックスを作成するかしないかのようです。

  ＳＱＬのＤＢにはあまり使用しない方がよいのかもしれません。

  昔の遺産かもしれません。

  私の認識ですので違っているかもです。
• 

  nkmt

  • 2021年03月19日 22:55

  自分で作った「お客様担当者マスタ」という物に、更新日の降順仮想キーを設定した件ですが
  このシステムは多数のお客様に収めているので、仮想キーだと物理変換が生じなくて
  都合が良かったという点もあったかもしれません。たぶん
• 

  群馬のマジシャン

  • 2021年05月06日 05:24

  皆さん、ありがとうございます。

  nkmt さんからの情報のように、自分（自社）で作成したのではない、○○マスタ　を参照する際に使う。たしかに！

  以前、どなたかに教えて頂いたような気がするんですが。仮想キーは、結局インデックス使わないので、OrderByが掛かるだけ。

  tandaさん、HELP　見てみます

   

  ありがとうございました。

  ISHIJIMAさん、過去の遺産。そうですね。そうかもしれません。。

   
• 

  tanda

  • 2021年05月08日 05:51

  そうですね、たしかにOrderByが掛かるだけのようですね。したがって、Magicの自前のソートより高速な処理になるのが利点のようですね。
• 

  群馬のマジシャン

  • 2021年05月09日 23:39

  tandaさん

   

  ありがとうございます。

  そうですね、処理速度対策で有効かもしれませんね。

  ありがとうございます。
• 

  tanda

  • 2021年05月11日 05:08

  群馬のマジシャンさん

  MagicがSQLServer側の独自の機能を呼び出している場合は、表現が把握しにくいところがありますね。
• 

  群馬のマジシャン

  • 2021年05月11日 08:01

  tanda  さん。

   

  ありがとうございます。

  ちょっと漠然とした感覚で実キー、仮想キーを使っていまして。

  皆さんはどう使い分けされているかなぁとおもって投稿しました。

   

   
• 

  tanda

  • 2021年05月11日 08:11

  多分ですが、実キーで用意するとすごいファイルサイズになってしまうだろうなと思えそうな内容を仮想キーで用意しておけば、いざという時にそのキーを指定して一時的にOrderByでサクサクっと動くようになるのだろうなということを期待しています。ソートよりはるかに速いと思います。
• 

  ISHIJIMA

  • 2021年05月11日 08:20

  ヘルプを見るとよくわかりませんね

  ヘルプ内容

  対象となるインデックスをデータベースに入れるか、Magic xpaだけで定義するかを指定します。

  使用できる値は、「R=実キー」または「V=仮想キー」です。テーブルの新規作成時にそのインデックスをMagic xpaで作成する場合は、インデックスタイプを「R=実キー」に指定しなければなりません。

  ［インデックスタイプ］特性は、実行時には既存のテーブルに影響しません。例えば、エンドユーザがデータビューにアクセスする場合には、実インデックスを追加する必要があります。

  特にRDBMSのソート機能が利用できる場合は、プログラム内でソート処理の代わりに仮想インデックスを使用することはなるべく避けてください。この機能を利用することでレコードを任意の順序で取り出せるため、Magic xpaではソート機能が不要になります。
• 

  群馬のマジシャン

  • 2021年05月12日 04:00

  tanda さん。

  ありがとうございます。

  それ、いいですね！！

   

  ISHIJIMA さん

  HELP、たしかに。読んでも、すっきりとしませんね

   

  キーが必要（必須）なのは、Magic 側ですね。SQL Server のテーブル作成時には、キーが無くてもOKです。でも、キー、必要だしなぁ。

   

   
• 

  ISHIJIMA

  • 2021年05月12日 04:18

  昔の私の認識では機器等が非力でキーを増やすとパフォーマンスに問題があり

  キーが増やせない等でＭＡＧＩＣ側に機能の仮想キーを利用していたような・・・

   
• 

  nkmt

  • 2021年05月12日 05:19

  昔私が作成したPervasiveの売上明細データのインデックスは

  #1 伝票番号＋行番号

  #2 商品コード＋売上日

  #3 得意先＋現場＋売上日＋伝票番号＋行番号

  などなど、その他 ４つのインデックス（計 ７インデックス）ありました。

  書き込み時、パフォーマンスが落ちるのでしょうね。

  SQL Serverのデータも似たようにインデックス過多の作りの物もあります。

  あるシステムの見積明細データは、インデックス１個だけという作りの物もあります。
• 

  群馬のマジシャン

  • 2021年05月12日 05:43

  ISHIJIMA さん、nkmt さん

  ありがとうございます。

  確かに、実キーを増やすと更新系のレスポンスに影響でそうですよね。

  キーが欲しい　＝　対象データの絞り込みとかで有効活用したい。でも、増やしすぎると更新時のパフォーマンスが。。。

  落としどころがあるのでしょうね。

   

   

  前に、松本さん（ご夫婦？）が講師として開催されていた「SQL Serverパフォーマンス・チューニング」みたいなセミナーに参加しました。（東京に行きたかったという不純な動機3割ぐらい（笑））

  で、キーの重要性と、キーを増やすことの弊害などを伺った（とおもいます）そのセミナーは純粋に？SQL Serverでしたので・・・。

  OSのモニターとか色々の情報と合わせチューニングする（らしい）聞いたのに、一部の機能しか使用してない。（プロファイラーとか）

  改めて、最近のSQL Serverパフォーマンスチューニング等ググってみよう。

   
• 

  nkmt

  • 2021年05月12日 06:18

  プロファイラー　という機能知りません。
  横道逸れますが、販売管理などで件数や金額集計などSQL文多用しています。
  xpa になってからはSqlexecute関数も使う事があります。

サインインしてコメントを残してください。