こんにちは、堀川さん

>たぶん昔のテーブル設計を、そのままサーバーに持ち込んでいるのでしょうね

うっっ、そうなんです。

>テーブルを設計するときに、部品管理の点数は５点で良いのか、将来
>増える可能性はないのかを検討すべきだと思います
>
>いろいろ方法はありますが、例えば
>      （ [登録ID] ,  [利用者ID]  ,  [部品] ）の３列で、連結主キーとす
>る方法が、簡単でしょう
>こうすれば部品の個数管理は、可変となります
>また、（[登録ID] ,  [利用者ID]  ,  [部品] ）の組み合わせですぐに検索
>することができますね
>
>これを、部品1,2,3,4,5のように列方向で管理したために、部品番号検索を
>行うときに全ての部品列を調査しなければいけません
>
>何か特別な理由で、部品1,2,3,4,5,***,のように、列で管理しているのかな？

どうやら、最初はテーブル設計時の正規化の時に上記のようにしていたとのこ
とですが、行が増えてしまい、あまりにパフォーマンスが出ないので、１登録
単位で部品１００までと限定（以前は無制限）という構造に作り替えたようで
す。以前のテーブル構造で持っていた行はだいたい１００万行（レコード）あ
ったらしい。その中を全件検索するので遅かったそうです。何せ、部品が無限
個登録できる構造だったので、BOFからEOFまでサーチする仕掛けだったとか。
結局パフォーマンスの折り合いが付かず、正規化のルールからは外れますが「
列」をたくさん持ったテーブルになったそうで。

今やっている保守の仕事の他に、同じ問題を抱えている物件があって、同様に
「たくさんの列を持ったテーブル構造に作り替えて、サーチは一回で済ます」
事を迫られております。どちらかというと問題はそのための『１回こっきりし
か使わないのに作らないと駄目なデータ移行プログラム』を書かなきゃいかん
という手間ですね。とほほ。

<< FOX-SS >>