最後に、このアプリケーションで最も手間のかかった「現在処理中のデータだけをDataGridへ表示する」部分について、若干補足しておきます。
- リレーションとレコードの定着 -
テーブル「売上明細」には商品IDは記録されますが、具体的な商品名や販売単価は記録されません。これは、「売上明細」がこの処理全体から見れば「一次的な記録場所」であるからです。そのため、商品名や販売単価はテーブル「商品_mr」を参照して導き出せるよう、まだリレーションを保ったままとなっています。
しかし、最終的にはこれらの値はリレーションを断ち切った具体的な値（他のテーブルを参照しなくても把握できる固定的な値）として、別のテーブルに記録されなければなりません。そうしないと、商品の価格が改定されたり生産中止になったりした場合、過去の受注記録まで影響を受けてしまいます。このように、テーブル間のリレーションを断ち切って別のテーブルに固定的な値としてレコードを記録することを、「テーブルの定着」などと呼んでいます。
このサンプルでは、一日あるいは半日分の受注情報をテーブル「売上明細」にまとめて記録しておき、あとでまとめて別テーブル「累計売上_fx」に、定着する――という仕様を前提としていますが、定着処理については省略しています。
- レコード定着のタイミング -
この「定着処理のタイミング」が重要です。サンプルの仕様ではテーブル「売上明細」に複数の顧客との取引が記録されており、それぞれが伝票番号によって識別できるようになっています。そのためDataGridに「現在入力中の顧客からの受注データだけを表示する」段階で、伝票番号をキーにしてレコードを抽出するSQLを用いる──という面倒な処理が必要になった訳です。
もし、アプリケーションの仕様が「１人の顧客からの受注（１件の取引）ごとにレコードを定着する」という形になっていれば、テーブル「売上明細」に記録されているレコード群をそのままDataGridに表示すればよくなります。
但し、レコードを転記（一次的なテーブルから定着用のテーブルへ移動）する処理が頻繁に発生するため、システム全体のパフォーマンスが低下する可能性があります。こういった処理は、１台のサーバに対して複数のクライアントが同時にアクセスする形が一般的なので、ネットワークのトラフィックも増大するでしょう。
- パフォーマンス低下を避ける手段 -
このような問題を避けるため、一次的なテーブルや定着用のテーブルをクライアント側に配置し、受注処理がひととおり終了した時点で、まとめてサーバー上のテーブルにレコードを追記する――という仕様とすることもできます。その場合、前回紹介した伝票番号の生成処理（レコード件数から連番を生成）で矛盾が生じるため、クライアントごとに個別の番号を割り当て、伝票番号の一部にその個別番号を挿入して重複を避ける――といった工夫が必要になります。
いずれにせよ、これらは業務処理で配慮しなければならない基本的な問題であって、本コラムのテーマであるSQLとは直接関係のない事柄です。よって、これ以上は深入りしないことにします。こういった事柄に関しては、また別の機会にでも触れることとしましょう。
受注（販売）記録処理を例に、プログラミング言語からSQLを扱う方法を紹介してきました。
言語にはVisual Basic .NETを用いましたが、SQLとADO.NETの基本事項は他の言語でも同じです。サンプルを参考にして色々試してください。
 |
|
|
