私は顧客とサプライヤを持つWebアプリケーションを開発しています。顧客とサプライヤデータベース設計の問題
当初、私はCustomersテーブルとSuppliersテーブルの使用を考えました。
私が銀行取引を考えているとき、私は各取引が顧客またはサプライヤーを参照する必要があることに気づいたので、私は顧客とサプライヤーの両方を節約するBusinessという単一のテーブルを使用することを考えました。
銀行取引を一覧表示するときに得意先テーブルと仕入先テーブルを使用すると、両方のテーブルを検索して会社名を取得する必要があります。
私がビジネステーブルを使用する場合、私はビジネスタイプの列を使用し、すべてのビジネスタイプに可能なフィールドの和集合を持たなければなりません。
デザインに関するご提案はありますか？
質問する必要がある質問は、顧客とサプライヤの間で共通の情報です。情報（とその情報のを使用）がほぼ同じ場合、それらを同じテーブルに格納することはおそらくOKです。情報（またはその使用）が大きく異なる場合は、それらを別々に保管し、銀行取引に必要なものを含める間に共通の見解を作成する必要があります。
あなたのアイデアは両方とも、あなたの質問に対する有効かつ正しい解決策です。正解を知るには、アプリの意図した使用パターンを考慮して、どちらを優先するかを判断する必要があります。たとえば、顧客と仕入先を別々に表示するよりも頻繁にすべての銀行取引をリストアップしますか？
あなたの顧客はサプライヤーになることができますか？多くのビジネスでは、顧客はあなたから購入したエンティティであり、あなたはそれを売るビジネスであり、同じエンティティは異なる時間に両方のことを行うことができます。金融業界では、これらは「取引相手」と呼ばれています。金融取引システムは、別のテーブルに差別化されていません。
a）2つのタイプのオブジェクト（得意先と仕入先）が同じコインの単純に2つの側であるか、または基本的に異なるか、b）より保守的で、理にかなったデータベーススキーマ？
ビジネスロジックの観点とコアRDBMSの観点からの影響を考慮する必要があります。 TransactionテーブルのCustomerキーとSupplierテーブルの両方に外部キーを定義できるという価値はありますか？
お客様の結果とサプライヤの結果が混在するアプリケーションで実際に検索を行っていますか？その場合は、共通部分を結合してテーブルを分割したビューを作成することをお勧めします。アドレスや電話番号などの他の情報は別のディスクリートテーブルに格納できるため、多くの共通情報がリファクタリングされることに注意してください。
私は他の人たちの言い回しを繰り返したくはありませんが、お客様とサプライヤーの特定のユースケースでは、お客様のドメインに応じて注意するべきことは、お客様がサプライヤーになる可能性があるということです。
自動車部品の販売を行っているとしましょう。販売代理店は、他の販売代理店から部品を購入する際の顧客です（部品の再注文など）。したがって、ディーラーは顧客とサプライヤーの両方になることができます。
私は通常、ビジネスや会社のエンティティを定義することにより、顧客のサプライヤーとの関係をモデル化したい、これは我々が扱っている人を定義します。住所、住所などを定義します。次に、顧客がビジネスであり、顧客がビジネスの顧客であるため、顧客が誰であるか、顧客が誰であるかを定義します。その後、関係についての追加情報を顧客に飾ることができます。
あなたはサプライヤーと同じことを行うことができます。これを抽象化して1つの関係テーブルを持つこともできますが、複雑になり、意味を失うことはありません。
あなたの最善の答えはユーザードメインから来ていると思います。同じユーザー（同じ役割）が共通に維持する顧客とサプライヤーの情報はありますか？そうであれば、両方の目的のために情報を変更することができれば簡単です。もしそうでなければ、あなたは彼らに互いのデータを変更させ、誰も幸せにならないでしょう。あなたが別の購買や販売システムを持っており、それらにインタフェースする必要がある場合
同じ問題が生じます。またはEnterpriseシステムを（。その場合、あなたはおそらく、それが何をするかと一致する必要があります）持って
質問 - あなたはユースケースやユーザストーリーやから、あなたの要件を導出していますか...？
お客様とサプライヤ。違う。サプライヤーとバイヤー - 標準商業取引関係の2つの側面です。 「顧客」という用語はマーケティング部門にのみ使用されるコンセプトです。その意味はコンテキストに基づいており、特定のビジネスプロセスにとって抽象的すぎます。これは、顧客を「購入者」のような関係の1つのタイプとして定義した場合にのみ機能します。これは無意味で混乱するようです。
1つの組織/人は両陣営で存在しうるという考えは完全に偶然です。特定の関係者が両方のビジネス関係に存在することを知る必要がある場合、何らかの方法でこの情報を制御できなければなりません。また、ビジネスによって制御方法を指定する必要があります。同じパーティーが2つの異なる側面に関わっていることをビジネスが知り、記録することを可能にするビジネスルールが必要です。
ビジネスルールによってサポートされていない場合に動作し、データ構造を作成することはできません。それは本当に簡単です。