3

私は自分の会社がビジネスローンを管理するためのデータベースを設計しています。各ローンには、個人または企業の保証人を含めることができます。保証人は、借入ビジネスが失敗した場合の財政的支援として機能します。

関係するテーブルは3つあります。ローン、人、会社で、明らかな情報を格納します。私が抱えているジレンマは、ローンと個人または会社との関係を定義して、各ローンの保証人を知る方法です。これを行うために私が見ることができる3つの方法があります：

1.すべての個人または会社の保証人に対して、単一のテーブルGuarantorを作成します。

Guarantor:
 pkGuarantorID (int, primarykey)
 fkLoanID (foreign key mapping to the primary key of a row in Loan)
 fkPersonID (foreign key mapping to the primary key of a row in Person)
 fkCompanyID (foreign key mapping to the primary key of a row in Company)

このアプローチの問題は、保証人は個人または会社のみであり、両方ではないため、外部キーの1つが常に空白になることです。

2.2つの異なる種類の保証人を表す2つの新しいテーブルLoan_PersonとLoan_Companyを作成します。

Loan_Person:
 pkLoan_PersonID (primary key)
 fkLoanID (foreign key mapping to the primary key of a row in Loan)
 fkPersonID (foreign key mapping to the primary key of a row in Person)

Loan_Company:
 pkLoan_CompanyID (primary key)
 fkLoanID (foreign key mapping to the primary key of a row in Loan)
 fkCmpanyID (foreign key mapping to the primary key of a row in Company)

明らかにより正規化されており、おそらくより良いオプションですが、これを選択して結果を適切に結合または表示するには、もう少しロジックが必要になります。

3.個人または会社のいずれかを参照する単一のテーブルを作成します。

Guarantor:
 pkGuarantorID (primary key)
 GuarantorType (signifies either Individual or Company)
 fkGuarantorKey (foreign key mapping to a primary key in Person if GuarantorType is Individual, or mapping to a primary key in Company if GuarantorType is Company)

これも良いオプションのようですが、JOINを実行する前にGuarantorTypeの値をチェックする追加の手順が必要になります。

どの方法を追求するかについて誰かアドバイスはありますか？私は、同じような状況にあった人々から話を聞くことを望んでいたので、将来どのような頭痛が引き起こされるか、または回避される可能性があるかを知っています。

ご覧いただき誠にありがとうございます！

編集：@RBarryYoungからのリンクに加えて、同様の質問がある人は、これらの質問も役立つかもしれません：

4

2 に答える 2

2

私の意見では、明らかな最良または最悪の答えはありません。それぞれに長所と短所があります。考慮すべき点がいくつかあります。

解決策1-データの整合性は、CHECK制約を使用して1つのFK値を強制的に入力することで保証できます。

解決策2-あなたが言うように、データの保存には最適ですが、データのクエリにはあまり適していません。これらのうち、アプリにとってより重要なものはどれですか？

解決策3-これは機能しますが、にFK制約を定義することはできませんfkGuarantorKey。これにより、データの整合性の問題が発生します。「最悪の」解決策を選択しなければならなかったとしたら、これはそれでしょう。

Person解決策4-テーブルとCompanyテーブルを1つのLegalEntityテーブルにマージし、個人専用データと会社専用データの子テーブルを作成することも検討できます。その場合、テーブルは2つのFKGuarantorを持つ単純な多対多のリンクテーブルになります。これは、製品の多くの部分が同じ方法で人または企業のいずれかに対処する必要がある場合に適したソリューションです。ただし、製品が常に人と会社を異なる方法で扱う場合、それは実用的ではありません。

于 2013-01-03T20:48:42.937 に答える
2

これは、「カテゴリ関係」または（より一般的には今日）「複数テーブル継承」として知られているものです。制約に応じて、1つを実装するための少なくとも3つの異なる実行可能な方法があります。ここにあるこの記事：http ：//www.sqlteam.com/article/implementing-table-inheritance-in-sql-serverは、それらを実装する方法を説明するのにかなり良い仕事をしています。

于 2013-01-03T20:52:38.137 に答える