私のサイトのユーザーはファイルをアップロードできます。この質問の助けを借りて、ファイル ステータスをモデル化するための 2 つの設計を考え出しました。
ステータスの例 -削除済み、保留中、禁止、アップロード中
設計 A - 個別のテーブル
ファイル- file_id(pk) | user_id(fk) | ファイル名
禁止されたファイル- file_id(fk) | 禁止理由 | admin_user | 時間
削除されたファイル- file_id(fk) | perm_delete | 時間 | 削除済み
保留中のファイル- file_id(fk) | 開始時刻 | 待機中
設計 B - ピボット テーブルと個別の情報テーブル (両方)
ファイル- file_id(pk) | user_id(fk) | ファイル名
ステータス- status_id(pk) status_text
ファイルのステータス- file_id(fk) | status_id(fk) | info_id(fk) <--これは、このステータスに関する情報を格納する別のテーブルのレコードにリンクします (例: (ban_reason、admin_user、time))
禁止情報- info_id(fk) | 禁止理由 | admin_user | 時間
削除された情報- info_id(fk) | perm_delete | 時間 | 削除済み
保留中の情報- info_id(fk) | 開始時刻 | 待機中
設計 A に関する私の主な懸念は、ファイルを選択するときに、それらが禁止されているかどうかなどを確認するために複数のテーブルに参加する必要があることです。設計 B は、1 つのテーブルに参加するだけでよいため、結合を実行する必要がないようにすることを目的としています。 .
どのデザインがお勧めですか？
選択クエリはデザイン A では遅すぎるでしょうか?