公開する前に承認する必要があるユーザープロファイルの編集を保存する方法

Question

ユーザーがプロファイルに行った編集を、管理者に承認されるまで公開されない、または既存のライブデータに影響を与えない方法で保存する方法を見つけようとしています。編集したプロファイル用の2番目のテーブルを作成してから、承認時にデータをコピーしますか？すべてを1つのテーブルに保持し、編集可能なすべてのフィールドの_tmpコピーを作成しますか？これにベストプラクティスはありますか？

ご意見ありがとうございます。

Answer 1

別のテーブルを用意しておくといいですね。そうすれば、他のすべてではなく、変更されたものだけを保存できます。

Answer 2

簡単にするために、データベースの「ステータス」列を使用して、特定の行が公開されているかどうかを判断します。 SQLで、追加します

 WHERE status = 'published'

これは単純なサイトに適しています。

忙しいサイトでは、そのWHERE句を持たないことでパフォーマンスがいくらか向上すると思われます。保留中の編集を別のテーブルに保存するのが適切なオプションです。次に、INSERT INTO ... SELECT FROMを使用してライブテーブルに移動します。

Answer 3

アプリケーションに少しのワークフローを組み込むことができます。そのため、さまざまな状態（たとえば、入力、提案、承認など）を定義するワークフローテーブルがあります。

次に、これらの提案された変更を保存するPendingChangesテーブルを作成することもできます。提案された変更が承認されたら、変更をメインユーザープロファイルの変更にマージします。

Answer 4

このような多くのケースが（多くの異なるテーブルにわたって）ある場合、TempObjectテーブルを使用して、XMLまたはその他の状態への変更を承認されるまでシリアル化できます。

またはユーザープロファイルテーブルだけの場合、UserID + Approved（boolean）に一意のキーを設定できます。ユーザーが自分のデータを編集すると、ユーザーIDとしてApproved = falseとしてテーブルに入力され、承認するには、承認されたものを削除し、承認されていないものを（もちろんトランザクションで）承認済みに更新します。

結局のところ、すでにすべてのデータを保持する構造を持っています-再利用しませんか？

Answer 5

これは最も簡単なようです：VERSIONおよびSTATUSフィールドをUSERSテーブルに追加できます。次に、必要に応じて、STATUSフィールドを使用して、最も高いバージョンの行を表示します。これにより、レコードのバージョン管理も可能になります。

VERSIONとSTATUSにインデックスが付けられている限り、表示操作が実際に遅くなることはありません。インデックスを維持する必要があるため、行の追加は少し遅くなります。

Answer 6

最初のテーブルと同じ形式の2番目のテーブルでは、複数の変更を簡単にキューに入れることができません。

特定の構造を設計して、各変更要求を変更要求として記録することをお勧めします。誰が変更するのか、何が変更されるのか、何をするのか、誰がリクエストを行ったのか、いつなどのフィールド

その後、検証された場合/検証されたときに変更を適用するコードがあります。

これは、追跡しやすい監査証跡としても機能します。

同じテーブルで変更を加えることはせず、実装を緊密に結合し、後のメンテナンスを困難にします。独立性により、すべてがどれほど密接に結合されるかが減り、将来の柔軟性が高まります。