[pgsql-jp: 31374] Re: 取引先の分割や合併処理について
Chie.M
gontakun_72 @ yahoo.co.jp
2003年 10月 30日 (木) 12:48:40 JST
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>
pgsql-jp メーリングリストの案内