彩考グループ データベースのFAQ 最新技術の評価、落とし穴 メガネチェーン向けシステムのご案内 イエズスサッカークラブのご案内 Y2KからY3Kへ警告のページ
 コンピュータユーザー必須のリンク集 AVISユーザーのページ

★Xbaseユーザー必見、インデックスの自動修復A

@のインデックスファイル修復機能を少し進歩させたものをお届けしよう。これは現在オープンしているデータベースとそのインデックスについて修復する機能である。基本的に@と同じロジックなので説明は書略するが、実行すると現在選択されているデータベースのインデックスを調べて、破損していれば修復するか？をウィンドを開いて知らせ、判断できるようになっている。

ダウンロード（参照）は次をクリック。PR_NDX.PRG

★Xbaseユーザー必見、インデックスの自動修復@

Xbaseは今や過去のものと見られがちだが、扱いやすいデータベースとしてユーザーは根強く多い。Xbaseのデータベース自体は眼鏡であるが、システム稼動中に電源が落とされて、突然にシステムダウンするとインデックスファイルが破損してしまう事が時々ある。その辺がクライアントサーバ型システムと比較しての弱点であったが、システムを再起動した時点で破損したインデックスを調べだし、修復する機能があったらと思い簡単なプログラムを作って見た。理屈は簡単である。以下にその仕組みを示す。サンプルプログラムは長いのでソースコードをダウンロードできるよう用意した。
☆データベースを開きGOTO TOP、GOTO BOTTOM、GOTO RECC()/2、のインデックスキーの内容を変数に入れる。
☆次にその変数でインデックスを利用して検索する。
☆検索されたレコードのフィールドと変数を比較して、違えばREINDEXする。
※以上の作業を開いているデータベースとインデックスについて自動的に調べるために可能な限り変数を利用した。
※配列と変数の宣言、DECLAREとPUBLICは割愛している。

ダウンロード（参照）は次をクリック。SC_PRNDX.PRG

★Windows2000は早いか？

Arago for Windowsのあらゆる機能を酷使した処理プログラムの結果は、Windows98が44分31秒であったのに対して、Windows2000は32分19秒と圧勝した。WindowsNTとWindows98では大差がないので、Windows2000は早い。またハングの頻度も極端に低くなりすこぶる安定している。データベースユーザーは迷わずWindows2000に走って頂きたい。
★ACCESS2000で高速検索（1999.10.16）

ACCESS2000はフィールドの文字列の部分検索には不適当のようだと考えていたが、解決策を発見した。ここに17001003256005というコードがある。このコードは次のような意味を持っている。最初の二桁の17は会社コード、次の三桁001は店コード、次の六桁の003256は顧客コード（店別の）、最後の三桁は販売コード（客別）となる。ここで顧客を特定するとその顧客の販売履歴が表示されるという機能が欲しいのである。ACCESS2000のJetSQLにはSELECT文の拡張機能として次のような機能が用意されている。
********************************
SELECT TOP 25
出席番号, 名前
FROM 生徒
WHERE 卒業年度 = 1994
ORDER BY 5 段階評価の平均 DESC;
*************************************
SELECTに続くTOP 25は検索結果の表示範囲を25件に絞り込む機能である。ここでは上位を絞るようになっているが、LIST BOX等に表示する件数が仕様をオーバーする事を意図して用意されているものだと思う。先に述べたコードを部分文字列で高速に絞り込むには最初にその文字列にINDEXを設定する。そして以下のようにクエリに等符号を追加して検索してみよう。
*************************************（クエリ１）
クエリに等符号を追加したもの
SELECT *
FROM XTRAN
WHERE KCODE>='13001000661001';
*************************************
以上のクエリでは13001000661001以上のデータが全てヒットし瞬時に処理は終了する。
この性質を利用して範囲を決めて絞り込むとどうなるかをテストしたクエリが以下である。
*************************************（クエリ２）
SELECT *
FROM XTRAN
WHERE (((XTRAN.KCODE)>='13001000661' And (XTRAN.KCODE)<'13001000662'));
*************************************
クエリ２では文字列の先頭から11文字目までを一つの区切りとして661から662までを対象として検索できるのではないかと考えたものである。この結果は見事思い通りとなり、次の画面のように13001000661001から13001000661004までがヒットしリストされた。

*************************************（クエリ３）
SELECT *
FROM XTRAN
WHERE KCODE>='13001000661001' And KCODE<='13001000661999';
クエリ３は式のスタイルこそ省略されているが、クエリ２と基本的には同じである。検索キーについては実際にヒットさせる範囲を明確に表現してみた。
*************************************（クエリ４）
SELECT *
FROM XTRAN
WHERE KCODE>='13001000661*' and KCODE<'13001000662*';
*************************************
クエリ４の結果もクエリ２とクエリ３と同じだった。
*************************************（クエリ５）
SELECT *
FROM XTRAN
WHERE KCODE>='??001000661*' and KCODE<'??001000662*';
*************************************
クエリ５は全くヒットしない。検索コードにはワイルドカードは使えないようだ。
更に少し実験を続けよう。JetSQL特有のTOP 数値式という拡張機能をクエリ５では動かしてみた。このクエリにはちょっと癖があり、アスタリスクの位置に注意が必要だった。検索の結果は画面11のようになる。
*************************************（クエリ６）
SELECT TOP 10 *
FROM XTRAN
WHERE KCODE>='13001000661';
*************************************
結果は１０件目までのヒットに制限される。

★ベンチマークレポート（その１）

マイクロソフトのACCESS2000を使用してデータベースの構造を変えた時の検証結果が次の表だ。例えばここで使用した基本のデータベースは260808レコードで108フィールドあり、フィールドの合計は1033バイトある。このデータベースから検索のキーとなるフィールドを一つだけ抜き出して作ったテーブルを別に用意した。さて結果は思惑通りで、１フィールドの場合が76.23秒、108フィールドの場合が336.16秒となった。これはACCESS2000のインターフェースを利用してストップウォッチでの計測である。使用したマシンはDELLのOptiplexG1(IntelCelelon400MHz)に192Ｍのメモリ、約20ＧのＨＤというマシンである。OSはWindows98を使用している。ここでの検索はインデックスなしのものである。フィールドのサイズが約10倍となると、検索時間が約５倍となる。これは他のデータベースでも同様の結果となるのだろうか？今やマイナーな印象が強いが、最速のデータベースと言われるArago for Windowsで同様のテストを行った結果は１フィールドが12.01秒、108フィールドで50.34秒とやはり5倍程度の差が出た。しかしArago for Windowsは異様に早い。次のバージョン5.0では更に高速化されるというので驚きである。

Arago for Windows Arago for Windows ACCESS2000 ACCESS2000
テスト内容 1フィールド 108フィールド 1フィールド 108フィールド
20万レコード目のデータを検索 12"01 50"34 76"23 336"16
日付を1日分絞り込む 17"23 65"64 1"21 16"61
1件のデータを絞り込む 20"54 71"29 99"44 108"66

★データベースの基本的な使い方と考え方

1.データベースはその種類で分ける、だが分け過ぎも禁物である
プログラムを作るところまでは行かなくても、データベースでデータを管理したいと考えた時には、全てのデータを一つのファイルに押し込めるのは止めたい。時々、エクセルのシート上になにもかも置いているようなものを見かけるが、データを再利用する時に混乱したり、データ数や項目が増えたときに収集がつかなくなる。データベースの話をするときに、沢山の引出しが付いたタンスが引用されるが、一つの引き出しに種類の違う部品を入れるよりも、引出しを種類別に分けた方が使い勝手が良いのは当然である。ただ、引出しも１００個とか２００個になると色分けでグループ分けするとか、更なる工夫が必要になる。

2.データベースの名前付け
データベースの名前付けはこのグループ分けを想定したものにする必要がある。COBOLでは機械的なコード付けが義務付けられていたが、パソコン上のデータベースでは自由な名前付けでかまわないと思う。ただし、様々なプラットフォームで使えるデータベースと考えるのなら、ANKで8文字（拡張子を除き）を心がける必要がある。

続く......