データの扱い
これが一番重要なところなので、ゆっくりペースで
まずは、業務システムのエントリー系を考えることに集中してみる
表示関係はプログラム的にみてエントリーさえできれば何とかなるので
エントリーする画面を分類してみる
- いわゆるマスタメンテナンス
- 作業ごとに追記していくタイプ
- 関連を追加していくタイプ
- 承認とかあるいわゆるワークフロー
ざっとこんな感じの組み合わせ
んで、それぞれの画面に検索・一覧・表示・編集みたいな感じで画面がある
と・・・いうのが一般的な考え方らしい
間違えてるとは思わないんだけど・・・そもそも「マスタデータ」って何？？って疑問が！！
そもそもの歴史的な経緯からいえばデータは大きくマスタデータとトランザクションデータに分かれてて、トランザクションデータをためてマスターデータをバッチ処理で更新なんだけど、RDB使って即座に更新してもマスターデータって言うしなぁ〜みたいな（ｗ
データの扱いとして追加・削除・更新以外がないもの？ってほとんどのデータがそうだしなぁ〜
更新頻度とかデータの安定度とかそういうのをマスタデータと表現するのはちょっと違う気がする
ということで、マスターデータなんて概念は今の業務システムになくて良いわけです。
というかその概念自体もう要らない気がする
こう考えると・・・
エントリーする画面をまた分類してみる
- 作業ごとに追記していくタイプ
- 関連を追加していくタイプ
- 承認とかあるいわゆるワークフロー
この３つの組み合わせになる
で、マスタデータのつながりから・・・
たとえば、顧客情報を考えてみる。
顧客情報は顧客登録画面で登録して、顧客削除画面で物理的に削除するというシステムを作ったとき
その顧客とのやりとりは消えないし、消しちゃだめっていうのが業務システムの基本
＃どうしても名前とか消さないとだめな場合は適当な文字で埋めるとかそういう対策が必要なのは別の話
ここで重要なのは顧客削除画面は論理削除ってことになる。
じゃあその顧客が戻ったときには論理削除したフラグをもどして・・・ってなるなぁと
あるとき、戻す場合が多いから顧客に削除ではなく休止状態を作りたいという要望があったときは？とか、事前登録したいとか、そういう場合があると・・・データベース上では日付付きのフラグを追加して・・・と
ここで重要なポイント。
前提その２に書いた業務システムは仕事の流れに合わせるべきって考え方。
一般的なマスタメンテナンスとしての考え方なら顧客への操作は、登録削除更新の３つ。
実際の業務の流れから考えると・・・
顧客を登録すると、その顧客は登録済みの状態になって、登録済みの状態で値を書き換えても登録済みの状態のまま、削除すると無効な状態になる、
通常の検索などの操作では登録済みの状態を対象にする。
事前登録とか休止状態は状態と流れの追加として考える
っていう風に考えるのが業務の流れに沿った情報の管理の考え方。
ちっちゃいけど、この二つの考え方の違いがものすごく大きな差を生む
というのはこの３つの画面種類
- 作業ごとに追記していくタイプ
- 関連を追加していくタイプ
- 承認とかあるいわゆるワークフロー
上二つは値の追加か関連の追加程度であんまり変わらない。
承認とかのワークフローは状態の変化として扱える。
＃実際に状態管理専門のエンジンとワークフローエンジンのコア部分の機能差はほとんどないし（ｗ
ということで、業務システムで実際に存在している画面種類は一つだけ
- 情報の追加更新と状態の遷移
これさえあれば業務システムのエントリー系画面の要望は満たせる
ってことでいっぱい書き疲れたのでまた後日
＃こっから先はまだ元ネタをちょっとしか書いてないからペースダウンしつつ続行
次回は情報の状態管理について
あっそういえばGenのネタ書こうかなぁ〜
