database-design - ほぼ同一の 2 つのテーブル

Question

Android アプリケーションと JSON Web サービスを開発しています。両側にデータベースがあり、両方に同じデータベース スキーマがあります。

クライアント側では、Order、 QAP 、および Defect はサーバー側データベースからのコピーです。これらのテーブルに行を追加することはできません。

CRSユーザーには、欠陥名と、CRF、MAおよびの 4 つの列を含むフォームが表示されますMI。これらの 4 つの列に、ユーザーはいくつかの値を挿入します。欠陥の名前は ですDefect.description。CRS、CRF、MA、および MI の値は、最新のE-Reportの一部になります。

これらの値 (CRS、CRF、MA、MI) を保存するには、 eReportDefectを使用します。

私の問題は、ユーザーがさらに欠陥を追加できることです。Defectテーブルにさらに行を追加できれば問題はありませんが、できません。それを解決するためにUserDefectテーブルを追加しましたが、 eReportDefectとUserDefectの2 つのテーブルがほとんど同じであるため、これが良いアプローチであるかどうかはわかりません。

そして、EReport に記入されたすべての Defect に対して「別の問題」があります。ゼロ、1 つ、または複数の画像 (テーブルeReportDefImgおよびUserDefImg ) を使用できます。

この設計は「OK」ですか、それとも改善できますか?

Answer 1

主キーの定義に「古い学校」のアプローチがいくつか見られます。;-)テーブルに関してはeReportDefect、キーが冗長です。「defectId」はすでに一意であるため、「qapId」と「eReportId」はインデックスを大きくして遅くするだけです。この場合の列の位置も最適ではありません。 。Defect内では正しいですが、内DefectImgでは同じ間違いがありますeReportDefImg。

さて、要点に戻りeReportDefectます。テーブルを変更できない場合は、別のテーブルを作成する方法は他にありません。

もう一つ、画像。私が正しく理解していれば、テーブルを変更できるので、テーブルや画像テーブルもeReportDefImg必要ありません。UserDefImgこれらの3つのテーブルの代わりに、次の1つのDefectImgテーブルを使用できます。

PK image_id
FK userDefectId
FK defectId

userDefectIdIS NULLの場合、 defectIdIS NOT NULLはを指しeReportDefect、その逆も同様です。これにより、ストレージと時間のかかる結合UserDefectImgとeReportDefImgテーブルを節約できます。1つの画像が複数の欠陥に収まる場合、これらは実際に必要になります。