0

私はデータベースを設計していました。これがその外観のコンテキストです。

アプリケーションがあります。

アプリケーションには申請者がいます。

申請者（申請書）には、共同申請者がいる場合といない場合があります。

申請者は、人口統計、一般情報、雇用情報、参照などの情報を持っています...

共同申請者が存在する場合は、同じ情報があります：人口統計、一般情報、雇用情報、参照など...

私が提案したデザインは次のようになります。

 Table: application [pk: applicaion_id]

 Table: applicant   [pk: applicant_id, fk: applicaiton_id {references: application.applicaion_id} ]

 Table: co_applicant [pk: ( applicant_id {references: applicant.applicant_id},  co_applicants_applicant_id {references: applicant.applicant_id} ) ]

 Table demographic [pk: demographic_id, fk: appicant_id{references: applicant.applicant_id} ]

 Table employment [pk: demographic_id, fk: appicant_id{references: applicant.applicant_id} ]

等...

申請者テーブルには申請者に関する一般情報が保持され、類似の共同申請者には共同申請者に関する一般情報が保持されます

これがデザインの代替案です。

 Table: application  [pk: applicaion_id]

 Table: applicant    [pk: applicant_id, fk: applicaiton_id {references: application.applicaion_id} ]

 Table: co_applicant [pk: co_applicant_id, fk: applicaiton_id {references: application.applicaion_id} ]

 Table demographic   [pk: demographic_id, fk: appicant_id{references: applicant.applicant_id} ]

 Table employment    [pk: demographic_id, fk: appicant_id{references: applicant.applicant_id} ]

 Table co_applicant_demographic   [pk: demographic_id, fk: appicant_id{references: applicant.applicant_id} ]

 Table co_applicant_employment    [pk: demographic_id, fk: appicant_id{references: applicant.applicant_id} ]

co_applicantの各情報の表。

どのデザインを提案しますか、またはより良い代替案は、その長所と短所とともに非常に役立ちます。

編集：読み取り-クエリはかなり重い可能性があり、検索クエリも同様に集中する可能性があります。

4

1 に答える 1

0

「applicant」と「co_applicant」の間で多くのものを複製しています。特に、複製されたテーブルです。クレイジー。

それらをすべて「申請者」として扱い、テーブルは1つだけですが、テーブルapplicantには2つのFKがあります。applicationapplicant_idco_applicant_id

于 2012-10-21T02:19:13.030 に答える