[pgsql-jp: 31374] Re: 取引先の分割や合併処理について

[Chie.M]

Chie.Mです。
坂田さん、ご返答ありがとうございます。

> やはり、この場は PostgreSQL というDBMSの情報を交換することが
> 主な関心事なので、手を挙げようという人は少ないんでしょうか。
> 
> この種の話題はこのMLにはややそぐわないと思うんですが、
> 思いついたことを少々書きます。

そうですね。申し訳ありません。
DBの設計について情報交換するMLってないでしょうか^^;

調査分析から設計開発まで全部ひとりでやってるので
参考になるような情報がありましたら是非拝見したいと
思っていますので、よろしくお願いします。

とりあえず今回はこちらで続けさせていただきます。

> Chie.Mさんのメールを読んでいて思ったんですが、テーブル構造以前に、
> どのような要求があるのかが、イマイチわかりませんでした。
> 契約一覧表示や合算処理が挙げられていますが、それだけが
> できれば十分なのか否かがわからないと、データ構造を決めるのは
> 無理があります。
> ですが、以下ではそれで十分と想定して書きます。

書き方が悪くて申し訳ありません。

もちろん他にも多数の要求はありますが、この件にからむ要求は
記載した内容に対応できれば問題ないという状況です。

取引先と契約を絡めた情報の取得という要求がほとんどで、
取引先単独での異動処理等の情報取得は考えていません。
# これがあると更に面倒くさそうですが・・・。

> 設計上の考え方としては、まず会社間の合併や統合を(ERモデルで言う)
> 「多対多関連」で表現するのが良いと思います。
> 
> この多対多関連を表にすると、
> 
> 合併(旧社名, 新社名, 種別, 合併ID)
> 
> のようになりますね(上記の表で合併のみならず分割も記録できます)。
> 
> その上で、契約の表示や合算処理の際には、必要に応じて「合併」表を
> 参照すればよい、ということになるかと思います。

なるほどそうですね。
やはり別にIDを持たせる必要がありますね。

ただし、ここで
>> 1. ある会社の契約一覧を見たい

この要求に答えるためには、
「いつ時点での異動であるか」という時間軸での情報も
持たせる必要が出てきてしまいます。

これにより、坂田さんがおっしゃる以下の問題

> しかしながら、このようなやり方には(少なくとも)2つの問題があります。
> 
> (1) 契約の表示や合算処理に際して、SQLを使うならば、
> 　　上記の「合併」表を結合する処理が必要になる
> 　　⇒性能上不利になりがち。

上記の問題が、さらに複雑になってしまう、という問題が
発生してしまいますね。

そうすると、坂田さんが示唆してくださった方法のように、
契約テーブル側に契約一覧表示用IDを持たせるか、
元々私の方で考えていた
> ・契約書類用データに関しては、取引先マスタのIDだけでなく
> 　社名をテキストで持たせる事で、契約当時の社名を表示できるようにする
上記の方法などを併用する必要がありそうですね。

これらの方法は、契約情報のテーブルと絡めた場合のみにしか
適用できませんが、今回の要求ではこれで充分足りそうです。

> (2) 現在1つの会社ではあるが、過去に何回も合併や分割を繰り返している
> 　　会社の場合、過去にさかのぼってその会社の合算処理をすると、
> 　　その種の処理はSQLだけでは書けない。
> 
> そこで、実用上は会社の情報を記録しておく表を、以下のような構成にする
> のが良いのではないかと思います。
> 
> 会社(会社ID, 社名, 合算処理ID, 契約一覧ID...)

なるほど！複数回繰り返している会社に対応するためには
やはり、多対多の関係のテーブルが必要となりますね。

ここまでは全く想像していませんでした。
ありがとうございます。

> 問い合わせの方法としては、
> 
> 1. ある会社の契約一覧を見たい
> 　　1.1 その会社のIDで「会社」表を引いて、「契約一覧ID」を取得する。
> 　　1.2 その「契約一覧ID」を当該会社のIDとみなして、契約を記録した
> 	テーブルを検索する。
> 	(…すると、「契約一覧ID」は1つの値ではなく、複数のIDを入れないと
> 	まずいですね。適宜正規化してください)

そうですね。異動処理テーブル専用の一意のIDを振るとか…

　会社(異動処理テーブルID, 会社ID, 社名, 合算処理ID, 契約一覧ID...)

でも契約一覧IDと会社IDと両方持たせた方が、SQL処理的には楽ですね。
検討します。

> このようにすれば、上で書いた2つの問題点はかなり
> 軽減できるものと思います。
> (それでも、やはり結合演算が必要ではありますが)

ほんとに軽減できそうです！
目からウロコです。

本当にどうもありがとうございます。

> ただし、会社の合併や分割があった場合には、「会社」表をメンテして
> 「合算処理ID」や「契約一覧ID」を正しい値に設定しておく必要があります。
> 
> ただし、そのようなイベントの頻度は低いこと、かつ、必ず特定の
> 日から切り替わる(ある日の途中で社名が切り替わったりはしない)ので、
> 夜間バッチのような処理でも間に合うと思います。

そうですね。複雑な面倒であるにもかかわらず、滅多に使う事がない
（でもないと困る）という状況なので、いかに簡易に処理するかと言う事も
視野に入れて考えていきたいと思っています。

本当によい情報ありがとうございました。
大変参考になり、とても助かりました。

-- 
Chie <gontakun_72 ＠ yahoo.co.jp>