やっと頭の中で VBA がまとまってきた気が

ここ数年、ひどいVBAコードを見る機会が結構あった。それもそれなりにVBAに触れている人のコードだ。やはり「VBAの知識の体系化」の必要性を感じた。

そのことについて、いろいろ考えあぐねていた。
　・応急処置ではなく恒久処置をしなければならない。
　・いっぱしにVBAを使っている気になっている人にも役立たねばならない。
そう思いつつも、即効性を求める人たちが多いので、どうしようか、と。


結果。

やはり媚びることなく貫かねばならんことは貫く、という姿勢が重要かなと感じるようになった。今までの思考の延長線上で考えてもらっては本人たちのためにもならないだろう。
カテゴリ分けをどうしようかと考えている部分もあるが、それなりにまとまった情報は時間の許す限り出していければと思う。

インデックスの断片化が解消しないことがある

alter table [インデックス名] on [テーブル名] rebuild　でインデックスの断片化を解消することができる。SQL Server Management Studio でもテーブル名の下にある[インデックス]を右クリックすると再構成や再構築のメニューが出てくる。

しかし、断片化がきれいに 0 になるならいいが、場合によっては断片化が解消されない、時にはひどくなるケースもある。
再構築、つまり rebuild はキーを一度削除してからつけ直す処理であるが、これで解消されないってどういうことだろう？テーブルを再作成しても駄目なケースも・・。
ただ、これには傾向があるかもしれない。今のところ思うのは

・非クラスター化キーだけで構成されている場合に発生するケースが多いように思う。
・数字でも文字でも、値の乖離が大きい割に、値が偏在している場合に多いように思う。
　例えば、キー項目の値が一様に分布しているのではなく、1 ～ 4000 と 200000 ～ 206000 の２つの範囲に偏在している、というケースであるにというような場合（数値は実例ではなくモデル）である。

このへんはもうちょっと調べて見るなりしてみようと思う。

shrinkdatabase するとインデックスが断片化する？

SQL Server でデータベースのログを切り捨てるべく、バックアップを確保してから dbcc shrinkdatabase ([データベース名] , 10 ) のようなコマンドを実行してみた。そうすると、shrinkdatabase 前に最適化しておいたテーブルのインデックスが思いっきり断片化している・・・。

仕方ないので、alter table [インデックス名] on [テーブル名] rebuild でキーの再構築を図った。インデックス名を ALL とすれば、そのテーブルの持つインデックスをすべて再構築してくれる。

----------
追記
データベースの圧縮はインデックスを断片化するそうです。そのうちネタ元のリンクを張ります。