書籍、出版社、ソース（特定の書籍へのリンクなど）に関する情報を追加できるアプリケーションを作成しています。 各ユーザーは、書籍やジャンル（出版社など）に関する情報を追加または編集することができます。 。 ユーザーが書籍に関する情報を追加または変更すると、この情報は彼のためにのみ利用可能となり、司会者は情報の正確性をチェックしません。確認後、情報はすべてのユーザーが利用できるようになります。
私のデータベーススキーマhereが表示されます。
ユーザーが投稿した変更に関する情報はどのように保存する必要がありますか？ユーザーが投稿した変更に関する情報を保存する方法は？
少なくとも2つの基本的なアプローチがあります。
オプション1：パラレルテーブルの変更を保留します - このオプションでは、同一のテーブルを持つスキーマをメインスキーマに重複させますが、各テーブルには追加の編集関連情報このオプションでproposed_by、proposed_datetimeなどapproval_status、approved_by、
として、あなたはすべての提案された変更を追跡するだろうし、彼らはモデレータがそれらを承認した場合にのみ、テーブルの主なセットに書き込まれます。これらのパラレル・テーブルに提案された変更の履歴を保持するか、承認され拒否された変更を保留にして、保留中の変更のみを残すことができます。それはあなたのビジネス要件に依存します。
オプション2：トラックは、ステータスフラグとメインテーブルの変更を保留 - このオプションでは、あなたは、あなたのメインテーブルに身をオプション1からの変更追跡列を追加します。 status_flagの列を使用して、どのレコードが公式で、提案された変更が保留中であったかを示すこともできます。必要に応じて、拒否された変更を追跡することもできます。
どのオプションを選択できますか？すべてのデザインはトレードオフです。ニーズに応じて、これらのオプションのいずれかを使用できます。最初のオプションの問題は、すべてのテーブルを複製し、その上に変更トラッキング列を追加する必要があることです。 2番目のオプションの問題は、がというコードを読み取るコードが、保留中の変更をすべて除外して考慮する必要があるためです。
私はクリーンなコードのファンです。その理由から、私はおそらくオプション1に傾いているでしょうが、あなたのビジネス要件を知らないので、あなた自身の決定を下す必要があります。
