売上管理システム その４（完）
米国赴任時に開発した売上管理システムのご紹介です。
.
昨日までは画面構成のお話をしましたが、今日はデータベース設計のお話です。
.
画面構成が従来の帳票と呼ばれるものとはかけ離れていたので、データベースの設計も少し常識はずれなものになりました。
.
売上計上は従来１日１回のバッチ処理でしたが、まずそれを出荷処理が確定した都度処理する様に変更しました。（これだけでもかなり苦労しましたが。）
.
月に数十万件にのぼる出荷明細データを全件読んで集計すると数十秒の時間がかかりました。
.
画面構成が合計が先頭で、その内訳が下部に表示されるため、そのまま処理すれば何分もかかってしまいます。それは絶対に避けたい事でした。
.
レスポンスは遅くとも５秒以内、できれば３秒で表示されるようにするべきと漠然と考えていましたので、このシステム専用の集計用のデータベースをつくりました。
.
集計単位もドリルダウンを考慮すると多岐にわたるため、１つのデータベースの中にデータ区分という項目を設けて、集計単位毎のレコードを持つように設計しました。
.
.
うまく説明できないので簡単な例で説明させていただきます。
データ区分 製品G 製品小区分 製品コード 販売地域 地域小区分 得意先 売上数量 売上金額
DT1 製品G1 - – – – – xxxxx xxxxxx
DT1 製品G2 - – – – – xxxxx xxxxxx
DT1 製品G3 - – – – – xxxxx xxxxxx
DT2 製品G1 - – EAST – – xxxxx xxxxxx
DT2 製品G1 - – MId-East – – xxxxx xxxxxx
DT2 製品G1 - – West – – xxxxx xxxxxx
DT2 製品G2 - – East – – xxxxx xxxxxx
以下項目の組み合わせにより多数のデータ区分あり。
.
.
つまりデータベースに集計した値を持つわけです。
.
こうすれば、全社合計の４行を出す為には、DT1の３レコードだけを読めば良い事になり、レスポンスの問題は解決されるという理屈です。
.
ただ、このデータベースを更新する処理が１件の出荷データから１０件程度の集計値を更新するため重くなりましたが、業務全体に影響を与えるほどではなく、問題なく処理できました。
（汎用機は、バッチ処理には強いんです。）
.
でもこれは、データベース設計の常識からはかけ離れたものでしたが、システムのレスポンスはそれ以上に大事と考えていましたので、そのようにしました。
.
結果、出荷毎に売上が集計され、誰に問い合わせる事なく机の端末を叩けばすぐに答えがでる仕組みにしたことで、皆さんがシステムを使ってコミュニケーションや会議をしてくれるようになり、大きな成果を感じる事ができました。
.
.
今の常識＝非常識くらいの気持ちで取り組まれる事をお勧めします。
.
※このシステム構築には多くのITメンバーや先輩の助けを頂きました。感謝申し上げます。
2025年9月12日
コメントを残す