DBのフィールド値はグローバル変数である

にわかスクリプトプログラミングにとって、DBのフィールド値はグローバル変数である。

にわかスクリプトプログラミング
各画面ごとのスクリプト内でSQLを直接記述して、おのおののソースでDBアクセス/更新を行ってるプログラミング。スクリプトのお手軽さのまま書き始めて、そのまま最後まで突っ走ろうとする姿勢。

各ページでデータ取得/更新をそれぞれやってたら、あるテーブルのフィールド値がどの処理で使用されているのか、またどの処理で更新されるのかが、grepでもせにゃ分からない。

つまり、どこからでも参照でき、更新できる値になっているわけで、まさにプログラム全体から参照・更新できるグローバル変数と同じ。仕様書でグロー バル変数をきちっと管理する、なんてことはしないのと同様、DBフィールド値もプログラムレベルで制約をつければ、もっとよりよい構成になるのでは?

例として

例として、「物件テーブル」の「状態コード」フィールド。「新規登録」画面で「作成」となり、「作業手配」画面で「手配済」となり、「作業完了」画面で「完了」となる、典型的な、データの状態を表すフィールド。

「状態コード」を更新する箇所では、それぞれの画面の更新処理でUPDATEするSQLを実行し、「状態コード」を参照する箇所では、それぞれの画面でSELECTするSQLを実行する、ってのが普通の組み込み。

こういう風にすると、状態コードの流れがもっと複雑になって、状態遷移図みたいなのが必要なぐらいになってくると、管理しきれなくなってくる。

例えば、作成→手配済→手配キャンセル→手配済→修理済→再手配済→再修理済→売上済→完了... とかのように、

  • 一方通行でないループがある
  • ルートによって、同じ状態でも別の呼び名になる(修理済と再修理済、手配済と再手配済、みたく)

となっていて、さらに真ん中とかに状態コードを追加したい場合、それぞれ値を取得している処理のところに影響があるかどうか、チェックしないといけない。変更する場合は、複数の画面を直さないといけないかもしれない。

一つの解決策

こんな場合、一つの解決策として、「物件テーブル」を「物件テーブルオブジェクト」として扱う。データ取得メソッド、データ更新メソッドを用意して、このメソッドを使用してのみテーブル内容にアクセスできるようにする。

利点

  • フィールド値を使用/変更する箇所を限定できる。
  • テーブル構造が変わっても、オブジェクト内の処理で吸収できる。

欠点

  • テーブル同士JOINさせる場合の、オブジェクトとしての定義が困難。
  • 大量にデータを取得する場合、1オブジェクトずつ処理すると、パフォーマンスに難。

乱暴な結論:フィールドの取得/更新をラッピングしたくて、さらにそれをまとめるためにオブジェクトとして定義する。

モノのラッピングにより、その正しさを保証*1したり、冗長処理を付け加えられるという特徴を使った方法。


*1 データが正しいことを保証するのは、DBトリガーやPL/SQLなどでもできる。