テータの格納形式には配慮する

昔、COBOLでシステムを組んでいた際、シーケンシャルファイルの読み書きが一般的であった。固定長形式でシーケンシャルの順次読み込みで、ブロック単位で読み込まれる。ブロック化係数の調整により読み込み速度も違うので、ディスクの容量を効率よく使え、更にその中でも高速になるように、と考えたものだ。ランダムアクセスが必要ならVSAMを使ったりもした。
どのアクセス方法が何に向いているので、ここでは何を使おう、という設計は当然のようにしていた。

今、いわゆるオープン系ではデータベースを利用することが殆どだ。しかし、データベースを利用するにあたって、データベースのことを知らない人が意外に多い。

Insert、Update、Delete でデータが操作できるのはご存じだろう。
しかし、
・トランザクションの使い方が分かっていない。
・処理単位を一括にした方が遙かに効率がよいのにレコード単位で処理しようとする。
・更新しなくていいデータまで更新している。
という設計をするエンジニアは意外に居るのだ。

また、ある程度経験があっても、データベースがネックとなっている処理の効率を上げるための措置を考えられない、という人たちは信じられないほど多い。中には「処理のネックの殆どはDB処理なので、データベースIO関係は後で調整すればよい」と言い切る人まで居た。それも一つのやり方なのかもしれないが、あまりにも行き当たりばったりではないだろうか？
データベースのチューニング、というと難しそうだが、丁寧に潰していけばいくらかは効率が得られる。そのくらいのことは分かっていないと後戻りが必要になり、最悪は作り直しになる。

なお、テーブルごとにSQL文を生成するクラスモジュールを作成し、そこ以外でSQL文の生成をさせないようにすることを前に書いた気がするが、そうしておくことで「どのSQL文が」「どの頻度で使われ」「どれが処理ネックになっているか」も解析しやすくなる。その結果、SQL文自体をチューニングするのか、インデックスを作成するのか、等の方策も採りやすくなる。

言語ができても、データのI/Oの知識が弱いととんでもない成果物ができてくることがあるのだ。