September 12, 2007.

結合キィィィ！！

仮稼働したシステムの無線が上手く動作していなかった様子。メーカに調べてもらったところ、設定が不足だったらしい。機器設定はbaristaの担当だった。設置や動作試験は別担当者だったため、不足が検知できなかった。悔しい。ソフトに比べハード面での経験値がまだまだ足りないなと反省中。精進したい。

さて、仕事でテーブルを弄っていると相変わらず気になる設計にぶつかる。今日気になったのは結合条件の設計。例えば服屋さんの出荷リクエストがこんなTBLだったとする。

出荷REQ[服ID,サイズ,色,数....]

実際にどこにおいてある在庫を何個出荷するかをきめ、出荷実績を作る。こんな感じだ。

出荷実績[服ID,サイズ,色,数,倉庫,列,段.....]

さて、この出荷実績からあるレコードを選択して取得することを考えたい。服IDだけ指定してもレコードが複数取得できてしまう。IDから数まで全部指定しても一意とは限らない。２カ所から出荷しているかも知れないからだ。逆に倉庫、列、段を指定しても一意とは限らない。同じ場所に１商品しかおいてないとは限らないからだ。

で、結局、一意なデータを取得するためには全項目を指定する必要がある。ここで、伝票データを出力するための中間TBLを想像して欲しい。今のプロジェクトでの設計はこんなだ。

伝票TBL[服ID,サイズ,色,数,倉庫,列,段,商品名,値段,得意先名....]

で、伝票TBLから出荷実績を検索したり、その逆を行う際には先ほど上げた全項目で結合を行う。コードが長い。変更に弱い。色がない(==null)商品が登場したりするとあたふたする。最悪である。こんな物、出荷実績に一意な実績IDを採番して、伝票TBLにもそれをもたせてやればよい。結合条件が単純化するし、インデックス化による高速化も顕著だ。

さすがに実務で使っているTBL構造を書くわけにも行かないので、上記は即席の例として考えた物であり、憤りが伝わりにくいかも知れない。しかし、実にうっとおしいのだ。さらにいうと、本物は上記に加え、ヘッダと明細に別れているので、結合した物同士を結合し...等という構造になっている。「条件を組み合わせれば何とか結合できる」みたいなTBL設計は回避すべきではないだろうか。例によって「DBは素人なので正しいかどうかはわかりませんが」と責任も回避しておくが。

実務はまた追加仕様が発生。仕事量が1.5倍ぐらいになった。車買い換えに際し、神様が残業代をプレゼントしてくれているに違いない。非常にありがたいことである。

Copyright 2007 barista. All rights reserved.