意味ありコードの実装
ユーザが意味ありコードを要求する理由がよくわからないのだが、西田順生「作る前にコストダウンする技術―景気はいいのになぜ儲からないのか (PHPビジネス選書)」に意味ありコードの実例が載っていたので実装方法を考えてみる。
以下はGroup Technology*1を実現するために、個々の製品にGTコードを付与する話。
GTコードは、製品番号や部品番号に単なる連番を付与するのではなく、下図のように意味のあるコードを持たせます。
大分類では機能や用途、中分類では材質や大まかな形状、小分類では細かな形状や特性、その他の補足情報を意味づけしていきます。
大分類 中分類 小分類 意味 機能 材質 形状 桁 1桁目 2-3桁目 4-6桁目 「あの時の図面は使えないかなー。でもどこにあるのかなー？」
「○○課長、こんな使用の材料は過去使っていませんか？」「さて、どうだったかな？」
GTを活用すれば、このようなムダな仕事は皆無になります。
自分が見たい製品や材料について、GTコードを頼りに検索し段々と絞り込んでいけば、流用したいとか参考にしたい図面や仕様書が瞬時にしてコンピュータ上で取り出せるようになるのです。
思うに意味ありコードの仕事は
- 個体指示
- 分類
- ソート
であり、上記の例は「分ける」ためだけに使用する意味ありコードということになる。
意味ありコードをRDBの単一カラムとして実装すると地獄を呼ぶことは周知の通り。
この例では
- 大分類が36種類(英数字の数)を超えたらどうする？
- 中分類が複数の製品＝「材質が'AA'かつ'BB'」が出たらどうする？
- 材質のない製品・形状のない製品＝何かのサービスも登録するとしたらどうする？
といった問題が見えている。
1.のコードのパンク回避には十分な桁数を取ればいいとして、2や3の課題に対応するためには、
- 「個体指示」と「分類」は別々のコードで行うこと
- 1製品に対してN個の[大,中,小]分類を付与できるようにすること
が必要だろう。
結論、ユーザはGTコードを入力して検索できるが、システム内部にはGTコードのカラムは存在しない、という形にしておけばよい。
製品マスタ = { 製品コード(PK), 製品名, ... }
機能マスタ = { 機能コード(PK), 機能名 }
材質マスタ = { 材質コード(PK), 材質名 }
形状マスタ = { 形状コード(PK), 形状名 }
製品.機能 = { 製品コード, 機能コード }
製品.材質 = { 製品コード, 材質コード }
製品.形状 = { 製品コード, 形状コード }
おまけ
セミナーで聞いたのだが、正美氏のコード構築方法は
- 無意味な連番は使わない
- 意味ありコードを使わない
というものなのだそうだ。もちろん全くわからない。
わからないが、ヒントとして「関係の中で決まる属性をコードの中に織り込まない」ということは聞いている。
関係の中で決まる属性は1つの個体について1値とは限らないから、コードに織り込むと多値が出て個体指示できなくなるのを問題視しているのかなあとは思う。
*1:共通の材料や部品を使う製品をグループ化することで、図面や仕様書の反復利用を促進し設計を効率化する技術
