物品販売では販売先を顧客管理システムの形で把握するのですが、相手が個人の時と法人の時とがあります。法人でも法人そのものが相手の時と購入した人が法人の一部署を名乗る時があり、法人/個人の区別だと不十分の時があります。
掛け管理などは法人そのものが相手になります。法人以外は個人的信用に依存されます。簡便な顧客管理システムだと個人法人区分/名称/連絡先/住所程度の項目しかなく後の有効利用の範囲が限られてきます。 性別/生年月日/家族有無は個人属性ですし、部署名/担当者名などは法人属性です。 一部署の個人が法人名で購入した物品を法人として扱うと混乱の元になりかねません。システムでなく運用の問題ですが。
個人の情報としての所在地、連絡先、氏名etcと、会社の情報としての所在地、連絡先、名称、担当者、担当部署は自ずと別次元の項目です。
顧客システムの名称に法人名+部署名で登録しているが法人名で名寄せしたいなどの要求があっても手作業になるケースが多かったりします。
DB設計の際に一つのテーブルで対応しさらに、名称と個人名,所在地と住所を共有する設計を見たりするのですが、疑問に感じるのです、項目名称自体がシックリこないのが第一ですし、法人項目と個人項目が同時に埋まることはないので冗長さが目に付きます。
前述したように法人名で購入したが実態は個人使用であるケースもあるので、法人/個
人に加えて個(法)の3つの区分を提案したことがあります。「そんな区分けは聞いたことがない」と一笑されましたが、3つの区分が要るとの考えは変わっていません。
3種類の属性があるとして、おのおの独立したクラスにするのは不細工な気がします。
基底クラスを設定して継承関係を構築できないか。と考えたりするのですが、ムズイ。
共通項目って殆ど無いのですね 名称/氏名 も共用するには必要な項目長が違いすぎる。法人の連絡先も一つでなく代表があったりダイレクトインがあったり、法人所有の携帯だったり。個人の連絡先も固定電話、昼間連絡先、夜間連絡先(時間指定)、複数の携帯保持などあり、連絡先の項目は一つでは間に合わなくなってます。生年月日や性別などは法人には不要だし.....ん。基本クラスにできる項目って住所しかないの?、住所も法人所在地と郵便配達先が違う時もあり...改めてビックリ。個別情報はシステムとして識別せずに備考欄にメモって人の目で顧客の状態を判断しているのが妙に納得します。住所、連絡先ってファジーな項目だったんですね。
顧客テーブルと法人情報テーブル/個人情報テーブルは分離して設置するほうが良いと考える次第です。継承したクラス化は熟考の余地がありますネ、課題です。